[jsr294-modularity-eg] Simple Module System Proposal
Alex.Buckley at Sun.COM
Mon Nov 23 06:35:08 EST 2009
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
I suggest we continue the work on first-class runtime modules for
accessibility that was almost ready for EDR back in July.
More information about the jsr294-modularity-eg