Or, you know, you can use OSGi ( http://www.osgi.org/Main/HomePage )
One motivation for the module system is faster JVM boot time. OSGi doesn't help with that at all.
Java 9: The State of the Module System
11–20 of 59 posts
Re: Java 9: The State of the Module System
#12Will java drop the bc in the future ? (e.g. 1.4 1.5 1.6) With the time by, java have a heavier bc problem.
I believe older java versions are already incompatible with newer jvms. I couldn't find it explicitly stated but i'd be surprised if 1.4 code worked 100% correct on a 1.7 jvm.
My experience so far is that the list of incompatibilities (http://www.oracle.com/technetwork/java/javase/compatibility-...) between versions makes it nearly impossible to just drop code between versions. It will run, but often implementation details have changed causing significant bugs. Your mileage may vary
Re: Java 9: The State of the Module System
#13Earlier quoted context omitted.
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.
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. See also: http://wiki.osgi.org/w/images/thumb/e/e2/Classpath.jpg/500px...
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.
Re: Java 9: The State of the Module System
#14Or, you know, you can use OSGi ( http://www.osgi.org/Main/HomePage )
One motivation for the module system is faster JVM boot time. OSGi doesn't help with that at all.
Except they don't mention at all how a module system should lead to faster boot times. Sure you could come up with faster lookup for classes by picking the right JAR but OSGi and JBoss Modules already do this today.
They have a protoype that does AOT compilation [1] but that's only a prototype and the gains are meager.
[1] https://www.youtube.com/watch?v=d4B8sc7ltZk&list=PLX8CzqL3Ar...
Re: Java 9: The State of the Module System
#15Will java drop the bc in the future ? (e.g. 1.4 1.5 1.6) With the time by, java have a heavier bc problem.
What is "bc"?
Re: Java 9: The State of the Module System
#16Re: Java 9: The State of the Module System
#17Re: Java 9: The State of the Module System
#18Doesn't solve the versioning problem. That's a little disappointing.
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.
Given that it was initially promised for Java 7, I'm sure you're right.
Re: Java 9: The State of the Module System
#19Earlier quoted context omitted.
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. See also: http://wiki.osgi.org/w/images/thumb/e/e2/Classpath.jpg/500px...
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.
Re: Java 9: The State of the Module System
#20Earlier quoted context omitted.
One motivation for the module system is faster JVM boot time. OSGi doesn't help with that at all.
Except they don't mention at all how a module system should lead to faster boot times. Sure you could come up with faster lookup for classes by picking the right JAR but OSGi and JBoss Modules already do this today. They have a protoype that does AOT compilation [1] but that's only a prototype and the gains are meager. [1] https://www.youtube.com/watch?v=d4B8sc7ltZk&list=PLX8CzqL3Ar...
>Except they don't mention at all how a module system should lead to faster boot times.
They will switch from the basic jar (zip) format to a more optimized one. Additionally, with a modularized jre, it will load less modules (who use corba?). I'm quite sure there are additional reasons, but it's the 2 that I remember.