[jsr294-modularity-eg] Simple Module System Proposal
Alex.Buckley at Sun.COM
Mon Nov 23 19:31:47 EST 2009
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
- 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.
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.
> 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
>> 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.
>> jsr294-modularity-eg mailing list
>> jsr294-modularity-eg at cs.oswego.edu
More information about the jsr294-modularity-observer