[jsr294-modularity-eg] Simple Module System Proposal

[Alex Buckley]

BJ, Richard, Peter,

Thank you for sending this proposal, which carefully points out where 
the existing proposal is satisfactory and where you believe changes are 
needed. I will need some time to consider it fully.

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
> 
> 
> ------------------------------------------------------------------------
> 
>  
> 
> *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.
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
_______________________________________________
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg