Dynamic modules and bidirectional interoperation

[mark.reinhold at oracle.com]

2016/10/26 13:46:07 -0700, Thomas Watson <tjwatson at us.ibm.com>:
> 2016/10/26 13:15:24 -0700, mark.reinhold at oracle.com:
>> ...
>> 
>> 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.
> 
> 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.

Okay, between dynamic package resolution and readability cycles it seems
that you do need a dynamic API.  Thanks for the quick answer.

- Mark