[jsr294-modularity-eg] Simple Module System Proposal

[BJ Hargrave]

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.
  
JSR 294 
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. 

2.      Introduction 
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, 
run-anywhere. 

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. 

3.      Goals 

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 
module-info file.

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”) 
access.

4.      Non-Goals 

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. 

5.      Summary 

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
BJ Hargrave
Peter Kriens

-- 

BJ Hargrave
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...
URL: <http://cs.oswego.edu/pipermail/jsr294-modularity-eg/attachments/20090814/0b81bc1c/attachment-0002.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/jsr294-modularity-eg/attachments/20090814/0b81bc1c/attachment-0003.html>