Dynamic modules and bidirectional interoperation

[Thomas Watson]

> From: mark.reinhold at oracle.com
> To: Thomas Watson/Austin/IBM at IBMUS
> Cc: jpms-spec-experts at openjdk.java.net
> Date: 10/26/2016 03:15 PM
> Subject: Re: Dynamic modules and bidirectional interoperation
> 
> 2016/10/7 8:47:53 -0700, tjwatson at us.ibm.com:
> > Overall I think this approach with #NonHierarchicalLayers is worth 
> > pursuing.  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.
> 
> A question for you about #ReadabilityAddedByLayerCreator ...
> 
> In this approach, will the code that creates a per-bundle layer be
> able to specify all of the required reads edges at the time at which
> that layer is created?  Or will it need to be able to add reads edges
> at one or more later times?
> 
> If the answer is the former then the resulting API is likely to be
> much simpler.
> 
> - Mark
> 

For static wires we could provide the read edges up front at Layer 
creation.  The vast majority of wires would be static, but in OSGi we also 
have something called dynamic package resolution.  Dynamic package 
resolution would happen after layer creation.  Unfortunately the dynamic 
package resolution could result in the need to add a new read edge to a 
previously unknown module.

I suspect there will be an ordering issue for static wires though.  The 
proposal is to have a triplet for each Layer->Module->BundleWiring.  I'm 
not sure what you have in mind for inputs to layer creation, but if the 
static mapping is needed at layer creation (aka Function<String, 
Collection<Module>>) then each Layer->Module->BundleWiring triplet will 
need to be created in a specific order to ensure all required modules are 
created to satisfy the call to the mapping function.  This will also 
prevent the support for cycles which are allowed in OSGi resolution.  I 
would prefer a dynamic API here.

Tom