Seriously. I've been doing Java for years and it had been so long since I wrote public static void main etc. that I had to look it up. If you're writing mostly classes to be run straight-up from the command line, you're doing it wrong.
You can have a main method that instatiates an instance of the class, populates it with whatever it needs (including mocks if you're into that sort of thing) and then exercises the various methods of the object.
It's like IoC but without all the bread and circuses.
NB: it's been about 8-10 years since I did anything like that.
Running from the command line is good for something that can run headless but you want to see immediate success/failure type messages.
The other main use I had for programs run from the command line was small 'one-off' file format conversion programs. Once you've done half a dozen of these it's relatively easy to just bang out the ~100 lines of code to do this (including proper exception handling).
Would it be faster to write it out in perl? Well, if the regex is sufficiently simple then yes, if it is moderately complex then you still use far fewer keystrokes, but getting it to the point that it is correct, that's easier in Java. (Assuming you optimise for readability, something perl... struggles ... with)
(That's not to say that most of the classes are to be run from the command line, but each CLI program has to have a class with such a method.)
1. use a Java REPL, like BeanShell or Groovy (or write one).
2. call a Java server from the CLI
BTW: I find "you're doing it wrong" is so unreasoned that best ignored
For the stuff that I'm working on, the 1 second startup time is no biggie though. One CLI thing I wrote, for instance, crunched on genomics data for 3 minutes before finishing. By tuning tight loops and the like, I was able to get that down to 15 seconds, but even so, the extra second there is no biggie. Except for when the user uses the "--help" option. That extra second is tedious.
Maybe the "unix hostility" is due to platform agnosticism ("run everywhere"), servant of two (or three) masters. e.g. issues in file libraries and AWT. But py/rb/perl manage this OK... so idk.
BTW: bad practice to split up functionality (and loses many benefits of Java), but a performance solution would be a script that handles the "--help", and for anything else starts the JVM.
Seems a bit of overkill, but I like the idea of a transformation operating above the level of one language...
I suppose the logical conclusion is compilation of arbitrary Java source to a scripting language, according to the performance characteristics required. It's nice that it would retain semantics and be transparent to the user, while rebalancing performance trade-offs.
It seems as if it would be better to have have a JVM byte code to Python byte code translator, or something like that, if such a thing is possible. But I should think that it would be even better and easier to just have a version of the JVM (or an option on the JVM) that starts up much faster.
If you're happy with just Java, doesn't BeanShell start up more quickly? (I don't know, because I've never used it.)
Yes; or a JVM that starts up faster, and split the code between them in the same way.
I'm assuming there's a fundamental trade-off between startup delay and average speed, or we'd have had an instant option long ago. Um, if the problem is loading etc jars, this mightn't work.
But one could still detect byte-code calls with hard-coded string arguments (for "--help" and text) and compile that to python.