[jsr294-modularity-eg] Simple Module System Proposal

[Alex Buckley]

A few questions about scope and schedule if I may:

- How do you see the simple module system handling the thornier parts of 
resolution, e.g. when module A depends on modules B and C, can B and C 
each depend on different versions of module D? In other words, roughly 
how strict are the simple module system's constraints on class spaces?

- You mention that compilers must provide fidelity with the runtime with 
respect to access control. What about with respect to visibility?

- What timeline do you have in mind for the JSR if the EG proceeds with 
the simple module system? How will updates to the OSGi specification be 
aligned with that timeline?

Alex

BJ Hargrave wrote:
> 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_ <http://www.osgi.org/>_
> __hargrave at us.ibm.com_ <mailto:hargrave at us.ibm.com> 	
> 
> office: +1 386 848 1781
> mobile: +1 386 848 3788
_______________________________________________
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg