Live data from Hacker News

Java 9: The State of the Module System

openjdk.java.net

21–30 of 59 posts

Re: Java 9: The State of the Module System

#21
post #20

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.

The JVM already only loads classes on demand so if you don't use Corba it doesn't have any impact on you (maybe minuscule extra seek time reading the JAR).

Re: Java 9: The State of the Module System

#23
post #20

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.

> They will switch from the basic jar (zip) format to a more optimized one.

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

#24
post #10

Earlier 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.

> 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?

Re: Java 9: The State of the Module System

#25
post #9

Will 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…

I think so, the implementation is hard to control than jvms.As long as jvm can run older(e.g. 1.4) version bytecodes, jvms is compatibility, but what if jvm drop that, then support real type generic like C#, etc, that's would be wonderful.

Re: Java 9: The State of the Module System

#27
post #9

Will 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.

If you watch talks like The Secret History and Tragic Fate of sun.misc.Unsafe ( https://www.youtube.com/watch?v=4HG0YQVy8UM ) you'll see that there is a move to isolate unsupported APIs and to slowly remove them once they are replaced by supported ones, but in general code that uses public APIs should continue to work without recompilation for a long time.
Post reply on HN