Hacker News Reader

Comment by wiradikusuma | Hacker News Reader

Or, you know, you can use OSGi (http://www.osgi.org/Main/HomePage)

Use complex to achieve simple, that's Java Style, :P

Some realities are impossible to accept fully.

OSGi isn't that complex, it's more that modularisation is inherently complex and people try to wave that away. When thinking modularisation through you quickly end up wanting depencency managament, versioning, modules and dynamic updates (meaning no restart of the VM when updating a module), and combining all of this is inherently difficult to design, and some of the stuff the JVM wasn't really designed for from the beginning. OSGi solves all that in a quite nice way, but for political reasons Oracle doesn't want to use OSGi ('not invented here syndrome').

That's a naive solution. OSGi has a very specific target of embedded applications. Thanks to its classloader, its a headache to port existing libraries which weren't written with its classloader in mind. This leads to duplicate osgi safe versions in custom artifact repos.

In the end, not a solution, but a very nice environment and development choice if you are greenfield and in the target audience.

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.

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

Clear, but the single rt.jar will be replaced with a more convenient representation, so, as you said, the seek time will be reduced.

The jar files used to be memory mapped, and as far as I'm aware they still are. So there should be a noticeable improvement in seek time by eliminating never-used files.

You could also perhaps be looking at a situation in the future where the JRE can selectively exclude things at install time, which would be nice.

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

That's why it's called a modular jar. There is also this "jmod" file described as:

"For the purpose of modularizing the Java SE Platform’s reference implementation, the JDK, we will introduce a new artifact format that goes beyond JAR files to accommodate native code, configuration files, and other kinds of data that do not fit naturally, if at all, into JAR files. This format leverages another advantage of expressing module declarations in source files and compiling them into class files, namely that class files are independent of any particular artifact format. Whether this new format, provisionally named “JMOD,” should be standardized is an open question."

Edit: from http://mreinhold.org/blog/jigsaw-modular-images

"The internal files rt.jar, tools.jar, and dt.jar have been removed. The content of these files is now stored in a more efficient format in implementation-private files in the lib directory."

> For the purpose of modularizing the Java SE Platform’s reference implementation, .... Whether this new format, provisionally named “JMOD,” should be standardized is an open question.

That just talks about the JDK. There is no promise that normal applications can use this format.

Reply on news.ycombinator.com