Java Archives (JARs) are widely used as both the distribution and
execution format for Java applications. The JAR format dates back to the
mid-1990s, and it has not scaled particularly well in either of these
roles. JAR files are hard to distribute, hard to version, and hard to
reference in general.
Distributing a simple Java application is considered to be a complicated
task by many developers because it often involves creating a native
installer to package multiple JARs into a distribution unit, and it
sometimes involves converting the application into a Java applet or JNLP
(Java Network Launching Protocol) application for web-based deployment.
There is no built-in versioning support in the JAR format. There is no
reliable mechanism for expressing, resolving, and enforcing the
dependency of one JAR upon another. Referencing a JAR, moreover,
involves specifying it in the classpath. Since the path of a JAR may
change during deployment, developers are forced to fix up all the
references to the deployed JARs as part of the deployment process.
Developers also find it quite difficult to deploy installed Java
extensions (a.k.a optional packages) because they can easily run into
issues like versioning conflict and namespace collision. Java extensions
can currently only be installed into a specific Java Runtime Environment
(JRE); it is basically impossible to arrange for an installed extension
to be shared across multiple JRE installations.
The specification of the Java Module System should define an
infrastructure that addresses the above issues. Its components are
likely to include:
o A distribution format (i.e., a Java module) and its metadata as a unit
of delivery for packaging collections of Java code and related
resources. The metadata would contain information about a module, the
resources within the module, and its dependencies upon other modules.
The metadata would also include an export list to restrict resources
from being exposed outside the module unintentionally. The metadata may
allow subset of exposed resources to be used by other modules selectively.
o A versioning scheme that defines how a module declares its own version
as well its versioned dependencies upon other modules.
o A repository for storing and retrieving modules on the machine with
versioning and namespaces isolation support.
o Runtime support in the application launcher and class loaders for the
discovery, loading, and integrity checking of modules.
o A set of support tools, including packaging tools as well as
repository tools to support module installation and removal.
We also expect the Java Module System to expose the public Java SE APIs
as a virtual module in order to prevent unwanted usage of the private
APIs in the implementation.