Modular Source Code also known as JEP 201, authored by Mark Reinhold and owned by Alan Bateman was created on July 22, 2014. JEP 201, second among the JEPs lined up for JDK 9, will “restructure the JDK’s source code from a scheme used since 1997 into modules, improve the build system to compile modules, and implement module boundaries at build time”. However, JRE and JDK binary images will stay as they are and no module system will be introduced.
JEP 201 is described as a part of the first phase of JDK 9’s main feature – Project Jigsaw. One main goal of the Project Jigsaw is to “make implementations of the Java SE Platform easily scalable down to small devices”. In connection with Project Jigsaw’s development, it was mentioned by Reinhold in one of his previous blog posts that merging is advisable to be performed before Jigsaw nears its completion.
In a short message posted by Reinhold last August 18, 2014, entitled “JDK 9’s source code is now modular”, he announced that JEP 201 changesets have been merged into the JDK. The changes are now included in the latest Early Access Release for JDK 9 – 9 Build b29 which is now available for download.
Restructuring the source code at an early stage is driven by the following factors:
- JDK developers will have a chance to familiarize themselves with the “modular structure of the system”;
- Implementation of “module boundaries in the build” to maintain that structure moving forward;
- “Shuffling” of non-modular source code to modular will be prevented during the improvements on Project Jigsaw.
Sample codes and details of the proposed new scheme versus the current scheme have been presented at the JEP 201 site. Below is an excerpt from the site that shows an illustration and explanation of the new scheme they wanted to implement “in every repository in the JDK forest except for hotspot”.
In abbreviated form:
src/$MODULE/{share,$OS}/classes/$PACKAGE/*.java
native/include/*.{h,hpp}
$LIBRARY/*.{c,cpp}
conf/*
where:
$MODULE is a module name (e.g., java.base);
The share directory contains shared, cross-platform code, as before;
The $OS directory contains operating-system-specific code, as before, where $OS is one of unix, windows, etc.;
The classes directory contains Java source files and resource files organized into a directory tree reflecting their API $PACKAGE hierarchy, as before;
The native directory contains C or C++ source files, as before but organized differently:
- The includedirectory contains C or C++ header files intended to be exported for external use (e.g., jni.h);
- C or C++ source files are placed in a $LIBRARY directory, whose name is that of the shared library or DLL into which the compiled code will be linked (e.g., libjava or libawt); and, finally,
The conf directory contains configuration files meant to be edited by end users (e.g., net.properties).