This Specification uses the Java Platform Module System, specified by JSR 376, to modularize the Java SE Platform. This will make implementations of the Platform more easily scalable down to small devices, improve security and maintainability, and enable improved application performance.
Goals Divide the Java SE Platform into a set of modules that can be combined at compile time, build time, or run time into a variety of configurations including, but not limited to
A configuration corresponding to the full Java SE Platform
- Configurations roughly equivalent in content to each of the Compact Profiles defined in Java SE 8; and
Custom configurations which contain only a specified set of modules and the modules transitively required by those modules.
The definition of the modular structure makes a clear distinction between standard modules, whose specifications are governed by the Java Community Process, and other, non-standard modules. It also distinguishes standard modules that are part of the Java SE Platform Specification, and thereby mandatory in every Platform Implementation, from other standard modules.
Design principles The modular structure implements the following principles:
Standard modules, whose specifications are governed by the JCP, must have names starting with the string “java.”.
If a Platform Implementation contains any non-standard modules then the names of those modules must not start with the string “java.”.
If a module exports a package that contains a type that contains a public or protected member that, in turn, refers to a type from some other module, then the first module must grant implied readability to the second, via requires transitive. (This ensures that method-invocation chaining works in the obvious way.)
A standard module will typically contain API packages defined by its respective Specification; we refer to these as standard API packages. A standard module may also contain some non-standard API packages. If a standard module exports a standard API package then the export may be qualified; if a standard module exports a non-standard API package then the export must be qualified. In either case, if a standard module exports any package with qualification then the export must only target modules in the same Platform Implementation. If a standard module is a Java SE module, i.e., is mandated by this Specification, then it must not export any non-SE API packages, at least not without qualification.
A standard module may depend upon one or more non-standard modules. It must not grant implied readability to any non-standard module. If it is a Java SE module then it must not grant implied readability to any non-SE module.
A non-standard module must not export any standard API packages. A non-standard module may grant implied readability to a standard module.
An important consequence of principles 4 and 5 is that code that depends only upon Java SE modules will depend only upon Java SE types, and thus be portable to all Implementations of the Java SE Platform.
The module graph The modular structure of the Java SE Platform can be visualized as a graph. Each module is a node, and there is a directed edge from one module to another if the first depends upon the second. The full module graph has too many edges to be displayed easily; here is the transitive reduction of the graph, in which redundant edges are omitted (click to enlarge):
Here is a guided tour of the module graph:
If one module depends upon another, and it grants implied readability to that module, then the edge from the first module to the second is solid; otherwise the edge is dashed.
At the very bottom is the java.base module, which contains essential classes such as java.lang.Object and java.lang.String. The base module depends upon no module, and every other module depends upon the base module. Edges to the base module are lighter than other edges.
At the top is the java.se.ee module, which gathers together all of the modules that comprise the Java SE Platform, including modules whose exported packages overlap with the Java EE Platform Specification. This is an example of an aggregator module, which logically gathers the content of other modules by granting implied readability to them, but adds no content of its own. A run-time system configured to contain the java.se.ee module will contain all the API packages of the Java SE Platform. A module is considered part of the Java SE Platform Specification if, and only if, it is a standard module reachable from the java.se.ee module.
The java.se aggregator module gathers together those parts of the Java SE Platform that do not overlap with Java EE.
The Java SE Platform module graph is an entirely new aspect of the Java SE Platform Specification. Its evolution will be governed by the JCP and is subject to the same evolutionary constraints as other APIs. Removing a module or changing it incompatibly, in particular, will require public notice at least one major release in advance.
Conformance Every Implementor of this Specification must implement the java.base module. Every Implementor may, further, implement a set of one or more additional standard SE modules so long as that set is closed, i.e., contains every standard module required by any member of the set. The Technology Compatibility Kit (TCK) for this Specification will be structured to allow testing of arbitrary configurations of SE modules present in a Platform Implementation. A Reference Implementation (RI) will be provided for each module, and for the entire Platform.
If an Implementation of this Specification implements a module then it must be complete, i.e., it must implement every API element of that module. This includes the module’s name, exported API packages, and any dependences that cause SE API packages to be re-exported. If an Implementation implements the entire Platform then it must implement every API element of the Platform. No other forms of Implementation are permitted.
Configuration files Minor changes to the API specifications for StAX, JAX-WS, and SAAJ were necessary in order to change how their factory methods locate service provider implementations. For StAX, the changes are specified directly in this Umbrella Platform Specification. For JAX-WS and SAAJ, the changes are specified in Maintenance Releases of their Component JSR Specifications.