[jsr294-modularity-eg] Simple Module System Proposal

[Richard S. Hall]

On 8/26/09 14:30, Alex Buckley wrote:
> 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?

I think there are two possibilities here:

   1. We simply allow multiple versions and provide a "class path" like
      approach where the versions are merged/shadowed based on the
      search order. In this particular example, the search order would
      be depth first like this: D1->B->D2->C->A. Clearly, this can lead
      to lead to class space consistency errors like with the class
      path, which leads us to the other alternative...
   2. We disallow multiple versions and this scenario would result in
      some sort of resolve exception.

It is not clear which is the best approach, but the safest is approach 
(2). We should discuss this in the expert group to reach consensus.

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

Yes, that was our intention.

> - 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?

Warp speed for the JSR itself. For OSGi, it is the normal spec process, 
which could take a year or so to finalize, but the work on RFCs could 
start immediately.

-> richard

>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/jsr294-modularity-observer/attachments/20090827/43b396e0/attachment.html>
-------------- next part --------------
_______________________________________________
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg