Earlier quoted context omitted.
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.
Java 9: The State of the Module System
21–30 of 59 posts
Re: Java 9: The State of the Module System
#22Re: Java 9: The State of the Module System
#23Earlier quoted context omitted.
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.
Straight from the article:
> A modular JAR file is like an ordinary JAR file in all possible ways, except that it also includes a module-info.class file in its root directory.
> A modular JAR file can be used as a module, in which case its module-info.class file is taken to contain the module’s declaration. It can, alternatively, be placed on the ordinary class path, in which case its module-info.class file is ignored
So no.
Re: Java 9: The State of the Module System
#24Earlier 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.
Huh? That sounds like a lot of work reinventing the wheel. Could you give me some details on how that's arranged?
Re: Java 9: The State of the Module System
#25Will 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…
Re: Java 9: The State of the Module System
#26Or, you know, you can use OSGi ( http://www.osgi.org/Main/HomePage )
Re: Java 9: The State of the Module System
#27Will 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.
Re: Java 9: The State of the Module System
#28Re: Java 9: The State of the Module System
#29Re: Java 9: The State of the Module System
#30Doesn't solve the versioning problem. That's a little disappointing.