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

[mark.reinhold at oracle.com]

2017/3/8 13:33:09 -0800, tjwatson at us.ibm.com:
> 2017/3/8 12:08:39 -0800, mark.reinhold at oracle.com:
>> 2017/3/8 6:09:11 -0800, tjwatson at us.ibm.com:
>>> ...
>>> 
>>> Most of the additional methods David Lloyd is suggesting is to get the 
>>> functionality needed to do the complete mapping of existing module systems 
>>> into JPMS.  Essentially I think we are trying to work with JPMS in order 
>>> to solve the following requirement [1]:
>>> 
>>> Interoperation -- It must be possible for another module system, such as 
>>> OSGi, to locate Java modules and resolve them using its own resolver, 
>>> except possibly for core system modules.
>> 
>> 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.

>>> ...
>>>
>>>  As I stated already, OSGi really only needs the addPackage and 
>>> addExportsToAll methods to be complete.  But this still requires double 
>>> resolution work to get us back to the functionality we were at with Java 8 
>>> and that is only if the suggested methods make it into java 9.
>> 
>> No changes to OSGi implementations, nor to JPMS, should be required in
>> order for OSGi implementations to achieve the level of functionality that
>> they have on Java 8.  An OSGi implementation should run just fine on top
>> of Java 9, without interacting directly with JPMS in any way.  (If it
>> doesn't then there's a bug somewhere, in which case please report it and
>> we'll fix it.)  What we've been discussing here goes well beyond the
>> functionality available on Java 8.
> 
> Understood.  Let me clarify.  With an enhanced OSGi framework that loads 
> OSGi bundles as JPMS modules/layers we cannot achieve the same level of 
> OSGi functionality as would be possible when running in the compatibility 
> unnamed module space (or on top of Java 8). 

Okay, got it.

- Mark