Java Platform Module System

The Java Module System implemented in Java 9 includes the following JEPs and JSR (Java Specification Request):[2]

• JEP 200: The Modular JDK: Define a modular structure for the JDK
• JEP 201: Modular Source Code: Reorganize the JDK source code into modules, enhance the build system to compile modules, and enforce module boundaries at build time
• JEP 220: Modular Run-Time Images: Restructure the JDK and JRE run-time images to accommodate modules and to improve performance, security, and maintainability
• JEP 261: Module System: Implement the Java Platform Module System
• JEP 282: The Java Linker: Create a tool that can assemble and optimize a set of modules and their dependencies into a custom run-time image[6]
• JSR 376: Java Platform Module System[7]

Additionally, several other JDK 9 features have been added to ease transition to the module system:

• JEP 238: Multi-Release JAR Files: Extend the JAR file format to allow multiple, Java-release-specific versions of class files to coexist in a single archive.[8]
• JEP 253: Prepare JavaFX UI Controls & CSS APIs for Modularization: Define public APIs for the JavaFX functionalities that is presently only available via internal APIs and would become inaccessible due to modularization.[9]
• JEP 260: Encapsulate Most Internal APIs: Make most of the JDK's internal APIs inaccessible by default but leave a few critical, widely-used internal APIs accessible, until supported replacements exist for all or most of their functionality.[10]
• JEP 275: Modular Java Application Packaging: The Java packager will evolve for JDK 9, making it aware of modules, allowing for example to package a module and all the modules it depends on.[11]

Modules are a new way of grouping code. Contrary to Jar files, modules explicitly declare which modules they depend on, and what packages they export.[12] Explicit dependency declarations improve the integrity of the code, by making it easier to reason about large applications and the dependencies between software components.

The module declaration is placed in a file named module-info.java at the root of the module’s source-file hierarchy. The JDK will verify dependencies and interactions between modules both at compile-time and runtime.

For example, the following module declaration declares that the module com.foo.bar depends on another com.foo.baz module, and exports the following packages: com.foo.bar.alpha and com.foo.bar.beta:

module com.foo.bar {
    requires com.foo.baz;
    exports com.foo.bar.alpha;
    exports com.foo.bar.beta;
}

The public members of com.foo.bar.alpha and com.foo.bar.beta packages will be accessible by dependent modules. Private members are inaccessible even through a means such as reflection. Note that in Java versions 9 through 16, whether such 'illegal access' is de facto permitted depends on a command line setting.[13]

The JDK itself has been modularized in Java 9.[14]

The Java Module System does not intend to support all the functionalities that the OSGi platform currently supports (for example the Life-Cycle model and the Services Registry). However the Java Module System will support functions which are not supported by OSGi, such as modularity at compile-time, and built-in support for native libraries.[15] A couple of articles exploring how the Java Module System and OSGi could interoperate were published in 2016. These can be found on InfoQ[16] and also the OSGi Alliance Blog.[17]

• Java package
• Classpath
• Java Classloader

• JSR 277
• JSR 294
• JSR 376
• Project Jigsaw
• The State of the Module System
• Java Platform Module System: Issue Summary