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

Thomas Watson tjwatson at
Thu Mar 9 13:47:24 UTC 2017

> From: mark.reinhold at
> >> To clarify, this requirement does not imply bidirectional 
> >> with dynamic module systems, as we've been discussing here.  All that
> >> this requirement means is that another module system must be able to 
> >> JPMS module metadata in order to resolve JPMS modules on its own 
> >> In the case of OSGi, e.g., a suitably-enhanced framework 
> >> could use the `java.lang.module.ModuleFinder` API to locate a 
> >> definition, and then use the `ModuleReader` API to read its metadata 
> >> 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 
> > these lines.  But I imagine there are going to be JPMS modules out 
> > that will not function correctly when their own classes start 
returning an 
> > unnamed module from Class.getModule().  In my opinion, for a JPMS 
> > 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.


More information about the jpms-spec-experts mailing list