JDK 9: Highlights from The State of the Module System

Dustin MarxSeptember 16th, 2015Last Updated: September 15th, 2015

0 21 4 minutes read

Mark Reinhold‘s The State of the Module System (SOMS) was published earlier this month and provides an information-packed readable “informal overview of enhancements to the Java SE Platform prototyped in Project Jigsaw and proposed as the starting point for JSR 376.” In this post, I summarize and highlight some of concepts and terms I found interesting while reading the document.

The State of the Module System states that a subset of the features discussed in the document will be used regularly by Java developers. These features and concepts are “module declarations, modular JAR files, module graphs, module paths, and unnamed modules.”
A module is a “fundamental new kind of Java program component” that is “a named, self-describing collection of code and data.”
“A module declares which other modules it requires in order to be compiled and run.”
- requires keyword seems analogous to OSGI‘s Require-Bundle or Import-Package
“A module declares which … packages it exports” to other modules.
- exports keyword seems analogous to OSGI’s Export-Package.
A module declaration is “a new construct of the Java programming language” that provides “a module’s self-description.”
- Convention is to place “source code for a module declaration” in a “file named module-info.java at the root of the module’s source-file hierarchy.”
- This module-info.java file specification of requires and exports is analogous to how OSGi uses the JAR MANIFEST.MF file to specify Import-Package and Export-Package.
“Module names, like package names, must not conflict.”
“A module’s declaration does not include a version string, nor constraints upon the version strings of the modules upon which it depends.”
“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.”
“Modular JAR files allow the maintainer of a library to ship a single artifact that will work both as a module, on Java 9 and later, and as a regular JAR file on the class path, on all releases.”
“The base module defines and exports all of the platform’s core packages,” “is named java.base,” is “the only module known specifically to the module system,” “is always present,” is depended upon by all other modules, and depends on no other modules.
All “platform modules” begin with the “java.” prefix and “are likely to include “java.sql for database connectivity, java.xml for XML processing, and java.logging for logging.”
The prefix “jdk.” is applied to the names of “modules that are not defined in the Java SE 9 Platform Specification,” but are “specific to the JDK.”
Implied Readability: The keyword public can be added after the requires keyword to state that a given module’s readable module can be read by dependent modules that read it. In other words, if module B references a package provided by module C as requires public, then that package is readable by module A that can read module B.
“The loose coupling of program components via service interfaces and service providers” is facilitated in the Java module system by use of the keywords provides ... with ... to indicate when a module provides an implementation of a service and by the use of the keyword uses to indicate when a module uses a provided service.
Because a given class is associated with a single module, Class::getModule() will allow access to a class’s associated module.
“Every class loader has a unique unnamed module” from which types are loaded that are not associated with packages exposed by a module. A given class loader’s unnamed module can be retrieved with new method ClassLoader::getUnnamedModule.
- An unnamed module can read all other modules and can be read by all other modules.
- Allows existing classpath-based applications to run in Java SE 9 (backwards compatibility).
“JMOD” is the “provisional” name for a “new artifact format” that “goes beyond JAR files” for holding “native code, configuration files, and other kinds of data that do not fit naturally … into JAR files.” This is currently implemented as part of the JDK and potentially could be standardized in Java SE at a later point.

The items summarized above don’t include the “Advanced Topics” covered in “The State of the Module System” such as qualified exports, increasing readability, and layers. The original document is also worth reading for its more in-depth explanations, brief code listings, and illustrative graphics.

Project Jigsaw and OSGi

Project Jigsaw, like OSGi, aims for greater modularity in Java-based applications. I look forward to seeing if the built-in modularity support can provide some of the same advantages that OSGi provides while at the same time eliminating or reducing some of the disadvantages associated with OSGi. In the article Mule Drop OSGi For Being Too Complex, Jessica Thornsby has summarized some developers’ thoughts regarding the perceived disadvantage of OSGi that have led Spring and Mule, among others, to stop using OSGi. The Thornsby article quotes Dmitry Sklyut, Kirk Knoerschild, and Ian Skerrett, who suggest that better tooling, better documentation (including by the community), better exposure at conferences, and more familiarity through use would help OSGi adoption and help overcome the perceived steep learning curve and complexity.

I will be curious to see if having modularity built-in to the Java platform will almost automatically bring some of the things that OSGi advocates have argued would increase OSGi’s adoption. I suspect that Project Jigsaw, by being built into the platform will have better tooling support, better exposure to general Java developers, and will be more widely and generally covered in the Java developer community (blogs, conferences, books, etc.). With these advantages, I also wonder if Java 9 and Jigsaw will cause current users of OSGi to move away from OSGi or if those users will find creative ways to use the two together or will do what they can (such as use of unnamed modules) to use OSGi instead of Jigsaw. Because OSGi works on versions of Java prior to Java 9 and Jigsaw will only work on Java 9 and later, there will probably be no hurry to move OSGi-based applications to Jigsaw until Java 9 adoption heats up. An interesting discussion on current and forthcoming Java modularity approaches is available in Modularity in Java 9: Stacking up with Project Jigsaw, Penrose, and OSGi.