Get the picture?
In the latest in Jigsaw puzzling news, we’re pleased to report that the initial change-set for JEP 220: “Modular Run-Time Images” was pushed through yesterday. As part of the steady granularisation of Java to improve performance, security, and maintainability, this JEP’s overriding purpose is slated as the remodelling of the JDK and JRE run-time images to accommodate modules.
According to a mailing-list release from Mark Reinhold, if you download the early-access build, or even put JDK 9 together yourself, you’ll be able to see these newly modularised changes for yourself.
The headlines around this JEP are that the “jre” sub-directory has been extracted from JDK images. Additionally, editable configuration files in the “lib” subdirectory have been ported to the new “conf” directory, and the endorsed standards override mechanism and extension mechanism have both been nixed.
Following Reinhold’s statement that he intended to smash all the JAR files (don’t worry – he just meant in Java – you can do what you like with them elsewhere), rt.jar, tools.jar, and dt.jar have been duly scrubbed out. Tools that were previously directly accessible via rt.jar can now be reached with a built-in NIO file-system provider, which, Reinhold comments, “has been defined to provide access to the class and resource files within a run-time image.”
Finally, a new URI scheme for naming stored modules, classes, and resources has been defined. Although there are a few lingering issues to polish off in JEP 220, this will be the most “disruptive” stage of the process.
These changes were preceded by last week’s announcement that, as part of JSR 375, which aims to define an “approachable yet scalable modular system for the Java Platform,” there had been an update to JDK binary image forms to accommodate modules with JEP 220. With JSR 375 in place and the modularisation of images in JDK 9 finalised, the leisurely train ride towards a fully modular Java is gradually picking up speed.
Image by Alain GAVILLET