Hacker News Reader

Comment by needusername | Hacker News Reader

My reading is it's hard enough as is because of backwards compatibility. They seem to be under massive pressure to deliver something for JDK 9 and can't push the deadline much longer.

If memory serves me correctly I remember Mark Reinhold saying to do it "right" they would have to run a linear equation solver like Eclipse/P2.

View on HN

It would seem that one of the JSR 376's key goals is to provide a saner way to manage dependencies than the Java classpath.

They say that but I don't know anybody who actually uses classpath (java -cp). Most people use a custom class loader, container and module system. In addition Oracle cops out of versioning. So I'm not sure who they are targeting.

The folks you work with seem to be more diligent than a lot of enterprise java folks I know. Explicit classpath is useful in deeply silo'd enterprise environment to get around multiple dependencies on incompatible versions of the same 3rd party jars. Often introduced while under the guns and then kept because maintenance dollars go elsewhere.

> Most people use a custom class loader, container and module system.

Huh? That sounds like a lot of work reinventing the wheel. Could you give me some details on how that's arranged?

The most extreme example is probably WildFly that has just the JBoss Modules JAR in the class path. That sets up class loaders for the modular service container that in term sets up class loaders for all the deployments.

Every Java EE server (even Tomcat) sets up its own class loaders. So does Jenkins/Hudson, Maven, all RCP platforms, even applets. It's really rare to find applications where all the code is in the class path.

Given that it was initially promised for Java 7, I'm sure you're right.

Reply on news.ycombinator.com