[jsr294-modularity-eg] Simple Module System Proposal

[Alex Buckley]

Hi Paul,

It is not really a topic for this list, but I fear there may be 
confusion, so I will be crystal clear:

- Sun has indicated many times that a Java SE 7 JSR is sought.

- Which JSRs are incorporated in the Java SE 7 Spec will be a matter for 
the Expert Group for the Java SE 7 JSR. Obviously I hope JSR 294 will be 
included.

- JDK7 will be the Reference Implementation of the Java SE 7 Spec.

- In addition to implementing JSRs, JDK7 will also have 
implementation-specific features, such as a) the classpath (never part 
of any JSR) and b) the Jigsaw module system.

- JDK modularization uses the Jigsaw module system. Module visibility is 
controlled by a prototypical module-info.java file; that may change. 
Module-private accessibility is actually not used in the modularization, 
partly to assist with bootstrapping.

- Further discussion of any aspect of Jigsaw belongs on the Jigsaw list.

Alex

Paul Benedict wrote:
> Hi Alex,
> 
> Thanks for the update! I don't know if you can answer this question,
> but it is more for the EG at whole. Until Sun defines a JSR for Java
> 7, isn't the work of modularizing Sun's JDK premature? I thought the
> future EG members of Java 7 have to vote in which specs they want in,
> which means JSR-294 isn't a slam-dunk yet.
> 
> Paul
> 
> On Mon, Nov 23, 2009 at 5:35 AM, Alex Buckley <Alex.Buckley at sun.com> wrote:
>> In the six weeks since the EG last discussed the Simple Module System
>> proposal, Sun has been making good progress modularizing the JDK's class
>> libraries and reengineering the JDK's language tools. (It is relevant
>> for the 294 EG to know broadly how the 294 RI is evolving.)
>>
>> javac can compile source files belonging to modules inferred from the
>> modulepath and will enforce full module-private accessibility Real Soon
>> Now. Long-standing issues with bootstrapping the JDK have also been
>> addressed, such that modularized JDK libraries are used properly and
>> early in the build.
>>
>> The libraries are modularized by mechanisms in the Jigsaw module system
>> including but not limited to recursive virtual modules, per-method
>> dependencies, packages split across modules, and structured
>> arbitrary-length versions. Sun finds these mechanisms useful for
>> compatibly restructuring vanilla packages in the JDK, and believes they
>> are applicable to clients of the JDK also.
>>
>> Clearly, the Jigsaw model goes some way beyond "named and versioned
>> JARs". How it overlaps with the OSGi model - designed for new, dynamic,
>> service-oriented applications - is not clear. Since both Jigsaw and OSGi
>> are defined in the first instance outside the JCP, it does not appear
>> that JSR 294 is well-positioned to define a module system that unifies
>> them. It would be a lowest-common-denominator design with
>> well-intentioned but irksome compromises. There has been no clear support in
>> the EG for the Simple Module System proposal, and I would like to take it no
>> further.
>>
>> Portability of modules between diverse module systems is important, but
>> should be handled by the module systems themselves. For example, Jigsaw
>> and OSGi already integrate with RPM and its panoply of dependency and
>> version features.
>>
>> I suggest we continue the work on first-class runtime modules for
>> accessibility that was almost ready for EDR back in July.
>>
>> Alex
>> _______________________________________________
>> jsr294-modularity-eg mailing list
>> jsr294-modularity-eg at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
>>