Mark Reinhold (Java's Chief Architect) has announced the relaunch of efforts to make Java fully modular. This news came in the form of a group of Java Enhancement Proposals (JEPs) that rejuvenates the Java modularity initiative known as Project Jigsaw.
Reinhold's vision is of four large JEPs that will each deliver an aspect of full modularity. The overall effort will be run under Project Jigsaw, which aims to deliver a modular JDK, although the official Oracle viewpoint is that this will not necessarily arrive as part of Java 9 (although if at all possible, it will be). This may be due to the experience of Java 8, where modularity was dropped from the release at a relatively late stage.
Despite this lack of firm commitment to the Java 9 timeframe, the first of the modularity JEPs appeared within the announcement of a group of features intended to become part of Java 9, as JEP 201 (titled "Modular Source Code"). In spite of this suggestive name, this JEP does not introduce modularity in any sense that is meaningful to a Java application developer. In fact, the Java 9 beta builds as they are currently being produced have no trace of modularity in the binaries.
Instead, this JEP is intended to be an incremental step towards modularity that is sufficiently small and harmless that it can be (and has already) merged into the OpenJDK 9 mainline. Effectively, all that JEP 201 intends to achieve is to alter the layout of the OpenJDK source tree so that it is now composed of modules.
Inside each module, the directory structure has also been rearranged, with the side-effect that the code that is common between Unix-like operating systems has been renamed to "unix" (it was previously called "solaris" for historic reasons).
The next JEP related to modularity aims to describe and set out the module structure but not actually implement it. The description of JEP 200 defines its purpose as:
Define a modular structure for the JDK. Make minimal assumptions about the module system that will be used to implement that structure.
These minimal assumptions include the idea that any module which starts with "java" is a standard module that will be governed by Java Specification Requests (JSRs), and will form part of the Java standard (for some future version of Java). In particular, such modules must have a public API that is portable between different Java implementations.
The source code layout changes that JEP 201 introduced set out these standard modules, and also bring in the concept of a "jdk" module to represent internal implementations that are specific to OpenJDK / Oracle JDK.
There is still a lot of work that needs to happen before the JRE is modularized and we see the end of a monolithic rt.jar. One specific stumbling block that caused problems last time is the classloading subsystem. In a modular ecosystem, classloaders need to be aware of modules, and in fact modules need to become the primary mechanism for loading code into a running Java process.
It remains to be seen whether Oracle are able to complete the necessary engineering work to deliver modularity in time for the Java 9 release train. However, the adoption of an incremental approach and separate JEPs for different aspects of the project is to be welcomed and offers a greater chance of success than previous attempts. Developers will be watching the progress of Project Jigsaw with interest.
