Dynamic modules and bidirectional interoperation

[Remi Forax]

----- Mail original -----
> De: "mark reinhold" <mark.reinhold at oracle.com>
> À: "Thomas Watson" <tjwatson at us.ibm.com>
> Cc: jpms-spec-experts at openjdk.java.net
> Envoyé: Mercredi 26 Octobre 2016 19:24:47
> Objet: Re: Dynamic modules and bidirectional interoperation

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

I fail to seen how this is not a mini-classpath with exactly the same issues as the classpath.

> 
> - Mark

Rémi