2.1 Please describe the proposed Specification:

This JSR will define an approachable yet scalable module system for the Java
Platform. It will be approachable, i.e., easy to learn and easy to use, so
that developers can use it to construct and maintain libraries and large
applications for both the Java SE and Java EE Platforms. It will be scalable
so that it can be used to modularize the Java SE Platform itself, and its
implementations.

2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.

This JSR targets Java SE 9. We expect the module system to be leveraged by
Java EE 9, so we will make sure to take Java EE requirements into account.

This JSR will only define a module system. It will not authorize the
modularization of the Java SE Platform, any other Java Platform Edition,
or any other JSR. Such changes are beyond the scope of this JSR and must
be carried out in some other, related JSR. We expect the modularization
of the Java SE Platform to defined in the Java SE 9 Platform Umbrella JSR.

2.4 What need of the Java community will be addressed by the proposed specification?

The proposed specification will address two fundamental needs of large Java
applications: Reliable configuration and strong encapsulation.

Reliable configuration — Developers have long suffered with the
brittle, error-prone class-path mechanism for configuring program
components. The class path cannot express relationships between
components, so if a necessary component is missing then that will not
be discovered until an attempt is made to use it. The class path also
allows classes in the same package to be loaded from different
components, leading to unpredictable behavior and difficult-to-diagnose
errors. The proposed specification will allow a component to declare
that it depends upon other components, as other components depend upon
it.

Strong encapsulation — The access-control mechanism of the Java
programming language and the Java virtual machine provides no way for a
component to prevent other components from accessing its internal
packages. The proposed specification will allow a component to declare
which of its packages are accessible by other components, and which are
not.

By addressing these needs, the proposed specification will enable three
further points of value for the Java community:

A scalable platform — The ever-increasing size of the Java SE Platform
has made it increasingly difficult to use in small devices despite the
fact that many such devices are capable of running an SE-class Java
virtual machine. The Compact Profiles introduced in Java SE 8 (JSR
337) help in this regard, but they are not nearly flexible enough.
The proposed specification will allow the Java SE Platform, and its
implementations, to be decomposed into a set of components which can be
assembled by developers into custom configurations that contain only the
functionality actually required by an application.

Greater platform integrity — Casual use of APIs that are internal to
Java SE Platform implementations is both a security risk and a
maintenance burden. The strong encapsulation provided by the proposed
specification will allow components that implement the Java SE Platform
to prevent access to their internal APIs.

Improved performance — Many ahead-of-time, whole-program optimization
techniques can be more effective when it is known that a class can refer
only to classes in a few other specific components rather than to any
class loaded at run time. Performance is especially enhanced when the
components of an application can be optimized in conjunction with the
components that implement the Java SE Platform.

2.5 Why isn't this need met by existing specifications?

The relevant existing specification in this space is JSR 291, which
established the OSGi Service Platform R4 Core Specification in the JCP. OSGi
is a rich and powerful dynamic-component framework which includes a module
system, a life-cycle model, and a service registry.

OSGi addresses the problem of reliable configuration but, since it builds on
top of the Java SE Platform, it does not provide strong encapsulation. We
intend in this JSR to consider changes to the Java programming language, the
Java virtual machine, and the Java SE APIs so as to address all the needs
listed above with improved usability, diagnosability, security, and
performance.

OSGi’s life-cycle and dynamic service-registry facilities are useful to some
kinds of sophisticated applications but are beyond the scope of the needs
outlined above. Those who require these facilities will still be able to
run OSGi on top of Java SE 9 implementations.

2.6 Please give a short description of the underlying technology or technologies:

A Java program component is organized as a set of packages. With a module
system the packages of a component are grouped into a module that governs
how they use other modules, and how other modules use them. Modules are
building blocks that allow an application to be composed from a set of
components independently of the details of their implementations.

A module is a named set of packages, resources, and native libraries. To
control how its packages use other modules, a module declares which other
modules are required in order to compile and run the code in its packages.
To control how other modules use its packages, a module declares which of its
packages are exported, and which are not.

The module system locates required modules from the universe of observable
modules and, unlike the class-path mechanism, ensures that different modules
containing packages of the same name do not interfere with each other. The
module system loads the code of required modules on behalf of the Java
compiler or the Java virtual machine. After loading, the access-control
mechanism of the Java language and the JVM prevents code from accessing
packages that are not exported by their modules.

To reduce coupling between modules, a module may declare that it uses an
interface whose implementation will be provided at run time by some module.
The module system binds implementations to interfaces and makes these
bindings available via the existing java.util.ServiceLoader API.

The module system will provide the means for a platform to which it is
applied, e.g., Java SE or Java EE, to run existing libraries and
applications without change, so long as such components use only standard
platform APIs.

Some members of the Java community have already invested significantly in
applications and frameworks built on top of the OSGi Service Platform. The
module system will provide a means for an OSGi kernel to locate Java modules
and resolve them using its own resolver, except possibly for core system
modules. This will enable OSGi bundles running in such a kernel to depend
upon Java modules.

2.7 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

The module-system API will reside primarily in the new package
java.lang.module. Related types in the existing java.lang,
java.lang.reflect, and javax.lang.model packages and sub-packages will be
defined or extended.

2.8 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

No.

2.9 Are there any security issues that cannot be addressed by the current security model?

The foundations of the current security model are adequate, but the model
will need to be extended so as to associate protection domains with modules.

2.10 Are there any internationalization or localization issues?

We expect the module system to provide a means to include localization data
in modules so that it can be accessed via the existing
java.util.ResourceBundle API.

2.11 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

The Java Language Specification, the Java Virtual Machine Specification, and
other elements of the Java SE Platform Specification will be revised by this
JSR.

What is the location of your publicly-accessible Issue list? In order to
enable EC members to judge whether Issues have been adequately addressed,
the list must make a clear distinction between Issues that are still open,
Issues that have been deferred, and those that are closed, and must
indicate the reason for any change of state.

Where is the publicly-accessible document archive for your Expert Group?

(See 2.20, below.)

Does the Community tab for my JSR have links to and information about all
public communication mechanisms and sites for the development of my JSR?

We intend this to be the case.

Do you have a Twitter account or other social networking feed which people
can follow for updates on your JSR?

Yes.

Which specific areas of feedback should interested community members (such
as the Adopt-a-JSR program) provide to improve the JSR (please also post
this to your Community tab)?

We are primarily interested in feedback on the usability of the module
system.

2.15 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

The RI and TCK will be part of the RI and TCK for Java SE 9.

2.16 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).

(Not applicable.)

2.17 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

2.18 Please describe the communications channel you have established for the public to observe Expert Group deliberations, provide feedback, and view archives of all Expert Group communications.

We intend to implement a trio of mailing lists in an approach already used by
earlier JSRs, including that for Java SE 8 (JSR 337):

Expert Group discussions will be carried out on an “experts” mailing
list, limited to Expert Group members.

The “observers” list will be for those who wish to monitor and, perhaps,
discuss the EG’s progress. Messages sent to the “experts” list will
automatically be forwarded to this list. Anyone may subscribe to this
list, and any subscriber may post. EG members are under no obligation to
follow the traffic on this list.

The “comments” list will be for sending comments, suggestions, and other
feedback directly to the EG. Only EG members may subscribe to this list,
but anyone may post. The EG will read all messages sent to this list,
and will record feedback in the issue tracker as appropriate.

The archives of all of these lists will be publicly readable.

2.19 What is the URL of the Issue Tracker that the public can read, and how does the public log issues in the Issue Tracker?

2.20 Please provide the location of the publicly accessible document archive you have created for the Expert Group.

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

This JSR is a central component of Project Jigsaw, a long-running
effort in the OpenJDK Community to design and implement a standard
module system for the Java SE Platform and to apply that system to the
Platform itself and to its Reference Implementation, the JDK. Relevant
documents include:

3.2 Explanation of how these items might be used as a starting point for the work.

The detailed goals and requirements of the overall modularization effort have
been discussed publicly for many years. They were most recently refined and
documented in the above-mentioned Goals & Requirements document,
which was published and discussed in July 2014.

Expert Group members are expected to be familiar with that document and
agree, in principle, with its stated goals and constraints. The EG will
begin its work by reviewing the requirements in that document relevant to
the module system and, if necessary, proposing and agreeing upon revisions
thereto.

An initial specification and prototype implementation intended to meet the
revised requirements will then be provided by the Specification Lead to serve
as the starting points of this JSR’s Specification and Reference
Implementation.

Related work described in the aforementioned JEPs and earlier work done in
the exploratory phase of Project Jigsaw may further inform the EG’s
discussions.