Oracle has begun removing JAR files from the Java runtime system as it searches for the final piece of the Java modularization puzzle.
The later the version, the nicer the features. Modularity is one of the most popular additions to Java 9. Having been postponed numerous times, Oracle is now declared "full steam ahead" for the introduction of a modular system to Java, also known as Project Jigsaw.
As confirmed by Mark Reinhold, head architect of the Java platform, the first changes planned by Java Enhancement Proposal (JEP) 220 have now been added to the Java 9 Early Access Build.
One of these changes is that the JRE subdirectory will no longer be in the JDK image. The Endorsed Standards Override Mechanism of the Extension Mechanism is also discontinued, as are the JAR files rt.jar, tools,jar anddt.jar. This could well be the beginning of the end for JAR files in the Java runtime system, although Reinhold has made it clear that this reduction is limited.
"We're not proposing to eliminate JAR files in general, but merely to stop using them inside the JRE and the JDK." – Mark Reinhold
For tools that need direct access to rt.jar, there's an internal NIO file system provider that provides access to class and resource files within a runtime image. The configuration files in the subdirectory lib are to be moved to the new conf directory. Finally, there's also a new URI naming schema for modules, classes and resources.
Further changes are to follow, however Reinhold has confirmed that the above changes are the most radical of all those that are planned.
First unveiled in October, JEP 220 aims at preparing modular runtime images for the Java Development Kit (JDK) and the Java Runtime Environment (JRE).
There are four JEPs of interest to anyone that's keeping a lookout for the latest buzzword 'modular'. JEP 162 (from all the way back in August 2012) still bears the vague name "Prepare for Modularization". It started shortly after Reinhold announced that the modularization project Jigsaw would not be part of Java 8 – sad news to many members of the Java community.
This postponement meant that modularization supporters would be forced to wait until version 9, arriving in 2016 at the earliest. On top of it all, modularization had already been pushed back from Java 7. This time, the authors made sure to add a disclaimer of "non goals" to make sure not give any false hope to the community.
"It is not a goal of this effort to integrate code for the module system, developed in Project Jigsaw, into JDK 8." – Jigsaw authors
Post-Jigsaw: 4 new JEPs
Last summer, after what deemed by the community to be 'Jigsawgate', JEP 200 and 201 quickly appeared, defining the modular structure of the JDK as well as modular source code. Shortly after, the latter was adopted into the OpenJDK Master Branch. JEP 220 is now the third stepping stone in modularization.
According to Mark Reinhold's goal plan (which was laid out in July 2014), there's one final JEP remaining:
A fourth JEP will introduce the module system itself, which will be aligned with the module-system JSR. It may seem odd that the module system JEP comes last, but the earlier JEPs need make only minimal assumptions about its capabilities, hence work on them can proceed in parallel with work on the module-system JEP and JSR.
There's still plenty of time for this final step before the planned release in 2016. Given the previous strides in the modularisation of Java, it looks safe to say that Project Jigsaw will indeed make its first appearance in Java 9. But after two postponements from as many releases, there's no telling when Oracle will manage to finish the modularization puzzle.
This article was originally published by Jaxenter.