This specification defines the Java Platform Module System.
The goal of this specification, as stated in the JSR, is to define an approachable yet scalable module system for the Java Platform. It must be approachable, i.e., easy to learn and easy to use, so that developers can use it to construct and maintain their own libraries, frameworks, and applications. It must be scalable so that it can be used to modularize the Java SE Platform itself, and its implementations.
This specification achieves that goal by providing two fundamental capabilities:
Reliable configuration, to replace the brittle, error-prone class-path mechanism with a means for program components to declare explicit dependences upon one another, along with
Strong encapsulation, to allow a component to declare which of its public types are accessible to other components, and which are not.
These capabilities are realized by treating modules as a fundamental new kind of program component that is defined by a construct of the Java programming language and interpreted uniformly at both compile time and run time.
This specification contains:
A summary of changes to the Java Language Specification (JLS) and the Java Virtual Machine Specification (JVMS) in support of module declarations, along with a summary of changes to align the entire JLS and JVMS with the module system.
A draft of the JLS and a draft of the JVMS, with change bars and dark blue text to indicate additions and modifications for the module system as summarized in the previous document. (Unrelated changes also in progress for Java SE 9 are red for addition and bright blue for modification.) The changes to the class-file chapter in support of module declarations are not included in this draft of the JVMS; they will be included in a future version of this specification.
Changes to the Java SE Platform API Specification, and the detailed differences. (The detailed differences contain a few changes that are unrelated to this specification but impractical to omit; in case of conflict the API specification is authoritative.)
Changes to the JAR File Specification.
Changes to the Java Native Interface Specification (JNI).
Changes to the JVM Tool Interface Specification (JVM TI).
Changes to the Java Debug Wire Protocol (JDWP).
Related external documents which may be of interest include:
The issue summary, which documents the history and status of issues raised, considered, and resolved thus far.
A design overview, which as of this writing is slightly out of date in some of the more advanced details but is nonetheless a useful overview of the essential concepts.
These two documents are cited for information only; they are not part of this specification.
This is a working draft of the specification. The following changes were made after the second Public Review Specification:
The specification of the
ModuleFinder interface was revised to say that if a JAR
file is used as an automatic module, and its main manifest includes
Automatic-Module-Name attribute, then the value of that
attribute defines the name of the module, per the accepted
The draft of the JLS was updated to clarify how a Java language compiler is meant to differentiate between packages with the same name in different modules.
In detail, the possibility of a compiler seeing the same package name
in multiple modules makes it necessary to specify (§4.3.4) that two
reference types with the same fully-qualified name must be
distinguished on the basis of the module that contains each reference
type’s declaration. Correspondingly, the notion of a package’s
“visibility” in potentially multiple modules is augmented by the
notion (§7.4.3) of a package’s “unique visibility” in a given
module. In effect, this considers whether a package is exported from
the given module. It follows that the meaning of package/type names
in code which
requires the given module is specified (§6.5.3,
§6.5.5) with regard to the “uniquely visible” package. Furthermore,
the scope of a top-level package declaration (§6.3) consists of the
compilation units to which the declared package is uniquely visible.
The specification of the module
system’s resolution algorithm, in the
package, was rewritten in order to clarify the definition of
readability and the means by which dependences are resolved at
In the second Public Review Specification the API specification was updated to make two significant changes:
LayerInstantiationException classes were
moved from the
java.lang.reflect package up into the
java.lang package and the names of the latter two are
Module, per the accepted proposal.