Dynamic modules and bidirectional interoperation
mark.reinhold at oracle.com
mark.reinhold at oracle.com
Wed Oct 26 16:15:45 UTC 2016
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
More information about the jpms-spec-experts
mailing list