Dynamic modules and bidirectional interoperation

[Thomas Watson]

> > 
> > 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.

Here I am using "system code" in the general sense, but I think any 
"system code" that cares about wiring will need to pay attention to 
Module::canRead like you suggest.  I can think of a few frameworks that 
care about how modules are wired up at runtime.  For example, in OSGi we 
have the extender pattern. Without going into much detail here, basically 
an extender implementation module will only act on extendee modules which 
are wired to the extender module.  If such a pattern exists using JPMS 
then the "system code" would be the extender implementation.

> 
> > 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.

The motivation for my question was to ask some follow-ons. 

Will there will be a specified order in which the nodes are traversed when 
there are multiple paths to a node?
More specifically will the parents have a specified order in which they 
are delegated to?

Tom