Dynamic modules and bidirectional interoperation

[mark.reinhold at oracle.com]

2016/10/26 9:32:42 -0700, Thomas Watson <tjwatson at us.ibm.com>, jpms-spec-comments:
> 2016/10/26 09:15:45 -0700, mark.reinhold at oracle.com, jpms-spec-experts:
>> 2016/10/7 8:47:53 -0700, Thomas Watson <tjwatson at us.ibm.com>, jpms-spec-observers:
>>> ...
>>> 
>>> 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.

Okay, I see.

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

Yes, the parents of a new configuration will be specified in an ordered
list and during resolution they'll be searched depth-first, in the order
in which they occur in the list.  Depth-first order makes it easy to
reason about resolution, since it works just like a search path.

- Mark