[jsr294-modularity-eg] Simple Module System Proposal
hargrave at us.ibm.com
Fri Aug 14 12:48:41 EDT 2009
Please find attached a proposal for a simple module system for Java. You
will have to excuse the formatting done by my e-mail client. I have
attached an html file which provides better formatting of the proposal.
Simple Module System Proposal
1. Executive Summary
This document proposes a simple concrete module system that supports a
subset of Jigsaw and OSGi as a replacement for the current proposal, which
creates a “black hole” where source files can only be understood with the
assistance of a specific module system. For example, at compile-time, the
module membership of a type is unknown without the assistance of a
specific module system. Additionally, the syntax of the module-info source
file is module system specific, forcing developers to make an upfront
decision for a specific module system. This proposal therefore seeks to
define a concrete and simple module system for Java that will have a fully
specified syntax, define a concrete module membership model for
compilation, and provide consistent and predictable visibility rules for
dependencies. This simple module system will allow developers to author
Java standard source code and to create Java standard modules which are
“drop-in” deployable into Jigsaw and OSGi runtimes. It is expected that
the capabilities of this simple module system will address most user’s
modularity needs, although it will defer support for more advanced
modularity use cases to other module systems.
The current JSR 294 proposal is the result of the expert group agreeing to
disagree on module system specifics. Since the expert group did not agree
on either OSGi’s or Jigsaw’s version numbering scheme, it was decided that
the version numbering scheme was a module system specific detail. Only a
specific module system could understand format and natural ordering of
version numbers. A developer creating a versioned module, must chose a
version number scheme and is thus bound to a specific module system.
Also the Jigsaw and OSGi module systems have different modes of accessing
dependent modules. OSGi has package-based sharing
(“Import/Export-Package”) with a module-based variation
(“Require-Bundle”). Jigsaw has module-based sharing with variations for
friendship (“permit”) and selecting the defining class loader (“local”).
As a result, it was decided to allow module system specific information to
be written into the module-info source file. Additionally, it was decided
to let the module system decide module membership via a compiler plugin,
making module access decisions depend on the chosen module system. The end
result being a proposal that is breaking the Java promise of write-once,
This proposal aims to concretely define a specification for a simple
module system for Java that will be supported by both Jigsaw and OSGi as
well as provide basic support for other module systems. The result is that
end users will be able to create Java standard modules which are "drop-in"
deployable into Jigsaw and OSGi runtimes, along with any other module
system implementing the simple module system specification. Success with
this proposal will require compromises on the parts of both OSGi and
Jigsaw stakeholders. But success here also means fulfilling the promises
made to the Java community by both Sun (Jigsaw) and OSGi to work together
to do the right thing for Java. This document is meant to be a starting
point for a new, simplified JSR 294 design and is offered in the hope of
cooperation and compromise. There are many details to be worked upon, with
the expectation and hope for substantive discussion and improvements on
the ideas and goals herein laid out.
1. Reuse from Current Proposal
To build upon the work of the expert group, the simple module system will
use, from the current proposal, the module keyword specifying module
accessibility for types and members, as well as the use of the module-info
source file to specify module metadata. The specification must continue to
support exploitation of the module access modifier by other module systems
such as Jigsaw and OSGi. For example, a module system must be able to
assign module membership of types at ClassLoader.defineClass() time so the
module boundaries can be defined by the module system.
2. No “black holes”
In order for this proposal to be truly valuable, it is paramount to have
no “black holes” in the specification, where black holes are things in the
source code which can not be understood without the assistance of a
specific module system. The specification must specify the concrete syntax
and semantics of the simple module system including version numbers,
dependency expression, module membership, etc. The Java language
specification does not allow one to define their own language keywords or
operators. The same must be true for module information in module-info
source files and for module membership rules.
3. Extension through Extra-lingual Means
Since there are no “black holes” in the specification, in order to express
features of a specific module system, such as Jigsaw or OSGi,
extra-lingual means must be used. In this context, extra-lingual refers to
things such as manifest headers, text files, annotations, etc. For
example, OSGi can continue to use manifest headers to describe
OSGi-specific features. Jigsaw can annotate a module dependency with
@jigsaw.Local. The use and appearance of such extensions makes it clear to
the observer that more than the standard simple module system is in use.
This specification must allow annotations on statements in the module-info
source. Then, if desired, module systems can define module system specific
annotations to overlay their additional semantics on the statements in the
4. Simple Visibility Model
The simple module system will define a single visibility model. When a
module requires another simple module, all the contents of this other
module are made visible to the dependent module. There is no proscription
against splitting packages across modules. This is what Jigsaw currently
does and is what most people, unfamiliar with OSGi’s more expressive
model, are likely expecting. It is very much what most people experience
today with Maven based build systems and the current runtime classpath
model. OSGi must update its specifications to provide support for this
simple visibility model, which is almost identical to Require-Bundle on a
bundle which exports all its packages. The simple module system must also
define a search order when looking up types in dependent modules.
5. Single Version Numbering Scheme
A single, shared version numbering scheme is necessary. The simple module
system must define a version numbering scheme and Jigsaw must use it and
OSGi must change to use it. The version numbering scheme must define a
natural ordering so that compareTo() can be used to order versions.
Currently, OSGi defines a 4-part version numbering scheme and a natural
ordering over it. Sun has stated the OSGi scheme does not meet Jigsaw’s
requirements. These requirements must be collected in order to design a
version numbering scheme and its natural ordering which can be shared by
the simple module system, OSGi and Jigsaw. OSGi must update its
specifications to support this new version numbering scheme.
6. Module Membership
For the simple module system, the compiler must assume that module
membership corresponds to the membership of the module artifact, for
example a JAR file or directory. At runtime, each module artifact will
have its own class loader that is associated with a single unique module.
All types loaded from a module artifact will be loaded by this single
class loader and made members of this single module.
Other module systems must be able to define different relationships
between artifacts, class loaders and modules to provide additional runtime
functionality. For example, Jigsaw could use one class loader to define
types for multiple modules (“local”) and OSGi could use multiple class
loaders to define types for a single module.
7. Compile-time Fidelity
For the simple module system, java compilers must provide compile-time
fidelity with the runtime for module and default (“package private”)
1. Define Jigsaw or OSGi Metadata
This proposal leaves to Jigsaw and OSGi how they will define the metadata
for using their module system specific features.
2. Compile-time Fidelity for other Module Systems
Enabling compile-time fidelity for specific features of other module
systems is out of scope for this specification. For example, OSGi
visibility rules or Jigsaw friends. To date, OSGi has not had compile-time
fidelity and, in general, it has not been a major issue.
3. Address All Uses Cases
The simple module system is not intended to cover all interesting use
cases for modularity. It is intended to be a simple module system which
will likely cover the majority of the modularity needs of most users.
Other module systems such as Jigsaw and OSGi can be used to address
modularity use cases not supported by the simple module system.
While there are details to be worked out, this proposal to concretely
define a simple module system for Java is in the best interests of the
Java community. Hopefully, the expert group will seriously consider this
proposal and OSGi/Jigsaw stakeholders will work together to make the
necessary compromises for maintaining the write-once, run-anywhere promise
of the Java language.
Jointly submitted by:
Richard S. Hall
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave at us.ibm.com
office: +1 386 848 1781
mobile: +1 386 848 3788
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the jsr294-modularity-eg