16 ms·

The Java ecosystem has a deeply engrained habit of doing expensive time-consuming things at startup too, like classpath scanning, eager caching and dependency i

by cle 5y ago

The Java ecosystem has a deeply engrained habit of doing expensive time-consuming things at startup too, like classpath scanning, eager caching and dependency injection, etc. GraalVM has a bunch of tradeoffs…executables can’t be cross-compiled, anything using reflection or other dynamic features are difficult to compile, only a subset of the standard library is (was?) supported, etc. Honestly there are much better languages to use for compiled CLIs these days, I would still steer clear of Java for CLI tools unless you need to reuse existing code. But I do agree with you that Java/JVM is a decent option for a WM, but using GraalVM would ruin all the nice properties of the JVM for that use case (JIT + dynamism).

pjmlp 5y ago
With a modern JVM, you can work around that expensive startup by making use of JIT caches.
KronisLV 5y ago
You know, it feels like you're right about the technical aspects, but there's an alternate point of view to be considered: maybe, in some circumstances, the dynamic loading and execution of code through reflection and other mechanisms actually is a bad thing? If i got a euro for every time i run into problems at runtime when porting Spring to Spring Boot or Spring Boot 1.X to Spring Boot 2.X projects, i'd have enough money never to have port projects like that over. Whereas without such dynamic logic, if your code compiles, you can be pretty confident that there won't be such oddities, classpath or dependency conflicts, weird scoping rules for Maven (especially with the <provided/> option which means that all of the sudden your app becomes dependent on an app server and its specifics - does your install of Tomcat or TomEE have the correct version of the .jar you want to use, or maybe it'll be missing, or maybe there'll be two libraries loaded at the same time?). Of course, picking a tech stack in which such approaches and dynamism aren't even prevalent is also a good alternative, though not everyone enjoys the more static way of development either.
- AtlasBarfed 5y ago
  You think java devs have it bad with ecosystem churn? The six months I spent in "modern javascript" was hilariously unstable. Classpath scanning is so unnecessarily hard in the JVM. I get they want flexible classloaders that may not have foreknowledge of the classes they can load, or that may not be simple zip/jars or filesystem-resident class files. But the fact that minority seems to doom classpath scanning to ludicrous workarounds and contortions rather than simply provide a "what classes do I know" api on the classloader that isn't a guarantee seemed ridiculous. The JVM should provide a cached map of the available classes. Jars/zips should optionally be able to provide a list/structure for fast scanning. "Full compilation" can still rely on shared libraries though, correct? Same boat there?

by cle 5y ago

pjmlp 5y ago

With a modern JVM, you can work around that expensive startup by making use of JIT caches.

KronisLV 5y ago

You know, it feels like you're right about the technical aspects, but there's an alternate point of view to be considered: maybe, in some circumstances, the dynamic loading and execution of code through reflection and other mechanisms actually is a bad thing? If i got a euro for every time i run into problems at runtime when porting Spring to Spring Boot or Spring Boot 1.X to Spring Boot 2.X projects, i'd have enough money never to have port projects like that over. Whereas without such dynamic logic, if your code compiles, you can be pretty confident that there won't be such oddities, classpath or dependency conflicts, weird scoping rules for Maven (especially with the <provided/> option which means that all of the sudden your app becomes dependent on an app server and its specifics - does your install of Tomcat or TomEE have the correct version of the .jar you want to use, or maybe it'll be missing, or maybe there'll be two libraries loaded at the same time?). Of course, picking a tech stack in which such approaches and dynamism aren't even prevalent is also a good alternative, though not everyone enjoys the more static way of development either.

AtlasBarfed 5y ago
You think java devs have it bad with ecosystem churn? The six months I spent in "modern javascript" was hilariously unstable. Classpath scanning is so unnecessarily hard in the JVM. I get they want flexible classloaders that may not have foreknowledge of the classes they can load, or that may not be simple zip/jars or filesystem-resident class files. But the fact that minority seems to doom classpath scanning to ludicrous workarounds and contortions rather than simply provide a "what classes do I know" api on the classloader that isn't a guarantee seemed ridiculous. The JVM should provide a cached map of the available classes. Jars/zips should optionally be able to provide a list/structure for fast scanning. "Full compilation" can still rely on shared libraries though, correct? Same boat there?