Concerns mapping existing dynamic module systems to a 1-1 Module->Layer

[Thomas Watson]

> From: mark.reinhold at oracle.com
> >> To clarify, this requirement does not imply bidirectional 
interoperation
> >> with dynamic module systems, as we've been discussing here.  All that
> >> this requirement means is that another module system must be able to 
read
> >> JPMS module metadata in order to resolve JPMS modules on its own 
terms.
> >> In the case of OSGi, e.g., a suitably-enhanced framework 
implementation
> >> could use the `java.lang.module.ModuleFinder` API to locate a 
module's
> >> definition, and then use the `ModuleReader` API to read its metadata 
and
> >> content to synthesize a corresponding OSGi bundle that's loaded by an
> >> otherwise-ordinary OSGi class loader.
> > 
> > I can confirm that this is possible, I have implemented something 
along 
> > these lines.  But I imagine there are going to be JPMS modules out 
there 
> > that will not function correctly when their own classes start 
returning an 
> > unnamed module from Class.getModule().  In my opinion, for a JPMS 
module 
> > to be loaded as a bundle in OSGi the classes for that bundle must be 
> > associated with a named module.
> 
> There may, eventually, be a few such JPMS modules out there, but I can't
> believe that they'll be all that common.  Unless the code in a JAR file
> is going to do deep introspection on its run-time module then it can
> remain blissfully ignorant of whether that module is named or unnamed.
> This is exactly why modular JAR files can be used on both the module
> path and the class path, and even on the class path of pre-9 releases
> with a little bit of care.
> 
> 
> - Mark
> 

My other concern is about perception.  It will not look good if an 
existing module system specification cannot take advantage of the new Java 
language features that are targeting modularity front and center.  I think 
it is in the best interests of our communities to make this possible.

Tom