3 ms·

The JVM is a double edge sword. It makes all of this possible. Not only can you generate code at runtime, Java will optimize it just as well as if it was origin

The JVM is a double edge sword. It makes all of this possible. Not only can you generate code at runtime, Java will optimize it just as well as if it was originally compiled in the application. I'm not sure why people harp on the JVM so much. JavaScript uses a runtime with even more magic that uses 5-10x as much RAM. I think the crappy JVM's of the past along with bad memories of Java Applets tarnishes its reputation unfairly

innagadadavida 8y ago
A major pain point with JVM even today is the startup time. This is especially true for command line tools. I use hdfs tools and it is really slow to start. Someone wrote a Go replacement that is 100X faster to start. None of the JVM sophistication means anything if it cannot solve simple common world problems. The java community has failed in this regard in my opinion. [1] https://github.com/colinmarc/hdfs https://github.com/colinmarc/hdfs
- thermodynthrway 8y ago
  This is actually being addressed, eventually. There's work being done to lower the startup time in Java 9-10 but I'm not sure what state it's in. Basically cache everything from the first run to make future launches almost instant
  - ptx 8y ago
    I played around a bit with that, i.e. app class-data sharing and AOT compilation. It turns out Java 9 comes with an enormous regression in launch performance, so that even with app CDS enabled it is slower than Java 8 to start. Java 10 is slightly better but still slower than Java 8 by default. Enabling app CDS gets you back to comparable performance to Java 8. With AOT enabled (in addition to app CDS) it might be faster, but that just crashes on machine (and only works on Linux anyway). So don't get your hopes up too much.
- sreque 8y ago
  Totally agreed that java fails hard for use cases involving small, lightweight binaries that are low memory and fast to start. This is an area where golang shines on the other. People are starting to experiment with AOT compilation via graal to make headroom in this space, but the techonology being used feels young, nascent, and experimental or immature: https://medium.com/graalvm/instant-netty-startup-using-graalvm-native-image-generation-ed6f14ff7692 https://medium.com/graalvm/instant-netty-startup-using-graal... https://www.innoq.com/en/blog/native-clojure-and-graalvm/ https://www.innoq.com/en/blog/native-clojure-and-graalvm/ Interestingly most high-level runtimes also have slow startup, including python, ruby, and node.js, but java's feels worse because people seem to want to use heavyweight frameworks like spring or aspectj that absolutely murder startup time, that for instance generate bytecode on startup or use classpath scanning to discover dependencies.
  - thermodynthrway 8y ago
    Yeah it's a bad trade-off developers don't realize they're making sometimes. Spring is Gigantic. Application containers like Tomcat aren't much better. It's easy to write huge apps in Java that still perform well so there's not much pressure to modulize huge monolithic libraries. So we all just deal with the 200+ deep stack frames. Newer frameworks like Vert.X and Dropwizard address this pretty well. We have a fairly large Dropwizard project that still starts in ~5 seconds. Also some written in Spring MVC that take 2 minutes... Also, God AspectJ let's you create horrible abominations. And it feels like it was designed to encourage you to do so. A great example of why you shouldn't always use self modifying code even if it's easy to do.
- rhencke 8y ago
  Keep your eye on Graal - specifically its native-image component. Not only do you get instant startup, you also get a statically linked binary that doesn't need a JRE present to run. Throw it a JAR - get a native binary for your system. https://github.com/oracle/graal https://github.com/oracle/graal
  - guitarbill 8y ago
    Someone used GraalVM to eliminate cold-start penalty for Lambdas, genius [0] ! I'm very excited about Graal, if only because it'd make deployments easier, but the debuggability remains to be seem. [0] https://news.ycombinator.com/item?id=17284022 https://news.ycombinator.com/item?id=17284022
- tytytytytytytyt 8y ago
  I would think the vast majority of uses of the JVM aren't for command line tools / anything where startup time even matters. > None of the JVM sophistication means anything if it cannot solve simple common world problems. It means plenty for all the companies that use it.

innagadadavida 8y ago

A major pain point with JVM even today is the startup time. This is especially true for command line tools. I use hdfs tools and it is really slow to start. Someone wrote a Go replacement that is 100X faster to start. None of the JVM sophistication means anything if it cannot solve simple common world problems. The java community has failed in this regard in my opinion. [1] https://github.com/colinmarc/hdfs https://github.com/colinmarc/hdfs

thermodynthrway 8y ago
This is actually being addressed, eventually. There's work being done to lower the startup time in Java 9-10 but I'm not sure what state it's in. Basically cache everything from the first run to make future launches almost instant
- ptx 8y ago
  I played around a bit with that, i.e. app class-data sharing and AOT compilation. It turns out Java 9 comes with an enormous regression in launch performance, so that even with app CDS enabled it is slower than Java 8 to start. Java 10 is slightly better but still slower than Java 8 by default. Enabling app CDS gets you back to comparable performance to Java 8. With AOT enabled (in addition to app CDS) it might be faster, but that just crashes on machine (and only works on Linux anyway). So don't get your hopes up too much.
sreque 8y ago
Totally agreed that java fails hard for use cases involving small, lightweight binaries that are low memory and fast to start. This is an area where golang shines on the other. People are starting to experiment with AOT compilation via graal to make headroom in this space, but the techonology being used feels young, nascent, and experimental or immature: https://medium.com/graalvm/instant-netty-startup-using-graalvm-native-image-generation-ed6f14ff7692 https://medium.com/graalvm/instant-netty-startup-using-graal... https://www.innoq.com/en/blog/native-clojure-and-graalvm/ https://www.innoq.com/en/blog/native-clojure-and-graalvm/ Interestingly most high-level runtimes also have slow startup, including python, ruby, and node.js, but java's feels worse because people seem to want to use heavyweight frameworks like spring or aspectj that absolutely murder startup time, that for instance generate bytecode on startup or use classpath scanning to discover dependencies.
- thermodynthrway 8y ago
  Yeah it's a bad trade-off developers don't realize they're making sometimes. Spring is Gigantic. Application containers like Tomcat aren't much better. It's easy to write huge apps in Java that still perform well so there's not much pressure to modulize huge monolithic libraries. So we all just deal with the 200+ deep stack frames. Newer frameworks like Vert.X and Dropwizard address this pretty well. We have a fairly large Dropwizard project that still starts in ~5 seconds. Also some written in Spring MVC that take 2 minutes... Also, God AspectJ let's you create horrible abominations. And it feels like it was designed to encourage you to do so. A great example of why you shouldn't always use self modifying code even if it's easy to do.
rhencke 8y ago
Keep your eye on Graal - specifically its native-image component. Not only do you get instant startup, you also get a statically linked binary that doesn't need a JRE present to run. Throw it a JAR - get a native binary for your system. https://github.com/oracle/graal https://github.com/oracle/graal
- guitarbill 8y ago
  Someone used GraalVM to eliminate cold-start penalty for Lambdas, genius [0] ! I'm very excited about Graal, if only because it'd make deployments easier, but the debuggability remains to be seem. [0] https://news.ycombinator.com/item?id=17284022 https://news.ycombinator.com/item?id=17284022
tytytytytytytyt 8y ago
I would think the vast majority of uses of the JVM aren't for command line tools / anything where startup time even matters. > None of the JVM sophistication means anything if it cannot solve simple common world problems. It means plenty for all the companies that use it.