Dynamic modules and bidirectional interoperation

[mark.reinhold at oracle.com]

2016/10/7 8:47:53 -0700, Thomas Watson <tjwatson at us.ibm.com>, jpms-spec-observers:
> Overall I think this approach with #NonHierarchicalLayers is worth 
> pursuing.

Glad to hear it!

>            A couple of observations.
> 
> 1) Any OSGi dependencies that influence class loader delegation will not 
> be declared in the ModuleDescriptors which represent the OSGi bundle 
> wirings.  Instead we will depend on the ability to 
> #ReadabilityAddedByLayerCreator to wire up the modules within the bundle 
> Layer according to OSGi resolution rules.  It has a drawback if there are 
> cases where some system code is trying to reason about modular 
> dependencies by using the JPMS module API.  I think this will have to be 
> acceptable because I don't think we will be able to fully converge on all 
> the possible dependency types available in the existing module systems. 
> For example, OSGi has Require-Bundle which maps closing to JPMS requires, 
> but OSGi also has Import-Package dependencies which cannot be mapped 
> properly into JMPS module Layers.

If by "system code" you mean code in the JDK itself, I don't think this
will be a big problem at run time.  Except for diagnostic purposes,
module descriptors are really only interpreted during resolution and
configuration.  All other run-time reasoning about module readability
is based upon the reads edges in the module graph as reported by the
`java.lang.reflect.Module::canRead` method, and that will include any
reads edges that you add to support bundle wirings.

> 2) I assume #NonHierarchicalLayers will be restricted to form a directed 
> acyclic graph.

Yes.

>                 As such I assume each node in the graph of Layers would be 
> visited only once when resolving new Layers on top even if there are 
> multiple paths to the layer from the new Layer being resolved.

Yes.

- Mark