3 ms·

I write Java programs that are designed to be run on the command line all the time. Just what is it that I am supposedly doing wrong? (That's not to say that m

I write Java programs that are designed to be run on the command line all the time. Just what is it that I am supposedly doing wrong? (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.)

6ren 15y ago
Speaking for CLI utilities (not apps in general), startup time is a killer. Python, Ruby, Perl etc are so much faster (despite Java improvements) since they began as "scripting" languages. One solution is to reuse a warmed-up JVM (even faster if also reusing already-loaded classes): 1. use a Java REPL, like BeanShell or Groovy (or write one). 2. call a Java server from the CLI I did (2) for a while, but not worth the saving of a second or so. BTW: I find "you're doing it wrong" is so unreasoned that best ignored
- nessus42 15y ago
  And if you use Spring, then the start up time is even worse! I do wish the JVM had an option that would make it start up instantly, even if it meant that the program would run slower. I wonder if the slow startup time has to do with the JVM having to dig through .jar files to find stuff. I'm also surprised that there isn't a way to cache the machine code generated by the jit so that the machine code doesn't have to regenerated on every run. It seems very strange to me that Java was invented by a Unix company, and yet it seems rather Unix-hostile. 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.
  - 6ren 15y ago
    Yeah, I'm puzzled by them not caching, e.g. they could copy an image of the JVM in its starting state. 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.
    - nessus42 15y ago
      I've actually used that hack for "--help", but I mostly use command line parsing libraries (e.g., JCommander) that generate the usage message for you. The users will just have to put up with the slight delay....
      - 6ren 15y ago
        Yeah, it's a pain to setup and maintain. Bizarre idea: a source transformer that knows about a CLI parsing library, to detect your usage of it and create the help option in a scripting language - and also provide the packaging (for the scripting language to start the JVM). Like Google's GWT for compiing a Java subset to JavaScript. 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.
        nessus42 15y ago
        Nooooooooooooo! We've switched largely to Scala! (But we're sill stuck with Java for GWT. :( )
        6ren 15y ago
        Sorry, I don't follow. Doesn't Scala have the same JVM startup delay as Java? Can do the same thing for Scala.
        nessus42 15y ago
        Yes, Scala is a JVM language, and all JVM languages that I am aware of have this start-up delay. One of the advantages of the JVM is that many different languages can interoperate easily, but if you do source-to-source translation to a non-JVM language, then the origin languages (e.g., Java) that have this extra support become preferred, and thus discourage the adoption of the better languages. E.g., GWT prevents us from completely migrating to Scala. 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.)
koko775 15y ago
Perhaps I should have clarified and added some more nuance. If the vast majority of the classes you write are, by design, intended to be directly run from the command line as their primary mode of execution, another language may be better-suited to what, to me, would sound like shell operations. Groovy, Python, or others may prove more concise and maintainable in such circumstance.

6ren 15y ago

Speaking for CLI utilities (not apps in general), startup time is a killer. Python, Ruby, Perl etc are so much faster (despite Java improvements) since they began as "scripting" languages. One solution is to reuse a warmed-up JVM (even faster if also reusing already-loaded classes): 1. use a Java REPL, like BeanShell or Groovy (or write one). 2. call a Java server from the CLI I did (2) for a while, but not worth the saving of a second or so. BTW: I find "you're doing it wrong" is so unreasoned that best ignored

nessus42 15y ago
And if you use Spring, then the start up time is even worse! I do wish the JVM had an option that would make it start up instantly, even if it meant that the program would run slower. I wonder if the slow startup time has to do with the JVM having to dig through .jar files to find stuff. I'm also surprised that there isn't a way to cache the machine code generated by the jit so that the machine code doesn't have to regenerated on every run. It seems very strange to me that Java was invented by a Unix company, and yet it seems rather Unix-hostile. 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.
- 6ren 15y ago
  Yeah, I'm puzzled by them not caching, e.g. they could copy an image of the JVM in its starting state. 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.
  - nessus42 15y ago
    I've actually used that hack for "--help", but I mostly use command line parsing libraries (e.g., JCommander) that generate the usage message for you. The users will just have to put up with the slight delay....
    - 6ren 15y ago
      Yeah, it's a pain to setup and maintain. Bizarre idea: a source transformer that knows about a CLI parsing library, to detect your usage of it and create the help option in a scripting language - and also provide the packaging (for the scripting language to start the JVM). Like Google's GWT for compiing a Java subset to JavaScript. 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.
      - nessus42 15y ago
        Nooooooooooooo! We've switched largely to Scala! (But we're sill stuck with Java for GWT. :( )
        6ren 15y ago
        Sorry, I don't follow. Doesn't Scala have the same JVM startup delay as Java? Can do the same thing for Scala.
        nessus42 15y ago
        Yes, Scala is a JVM language, and all JVM languages that I am aware of have this start-up delay. One of the advantages of the JVM is that many different languages can interoperate easily, but if you do source-to-source translation to a non-JVM language, then the origin languages (e.g., Java) that have this extra support become preferred, and thus discourage the adoption of the better languages. E.g., GWT prevents us from completely migrating to Scala. 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.)

koko775 15y ago

Perhaps I should have clarified and added some more nuance. If the vast majority of the classes you write are, by design, intended to be directly run from the command line as their primary mode of execution, another language may be better-suited to what, to me, would sound like shell operations. Groovy, Python, or others may prove more concise and maintainable in such circumstance.