Proposal: #NonHierarchicalLayers

[David M. Lloyd]

On 10/31/2016 03:22 PM, mark.reinhold at oracle.com wrote:
> Issue summary
> -------------
>
>   #NonHierarchicalLayers --- Layers are presently constrained to be
>   hierarchical, i.e., each layer has at most one parent.  Should this
>   restriction be relaxed so that a layer can have more than one parent?
>   Some have argued that this will be essential to the adoption of the
>   module system by a future version of the Java EE Platform.  It would
>   also enable bidirectional interoperation with existing module systems
>   such as OSGi. [1]
>
>
> Proposal
> --------
>
> Revise `java.lang.module.Configuration` and `java.lang.reflect.Layer` to
> augment the existing instance methods that treat `this` as the parent of
> the child being created with corresponding static methods that take a
> list of parents.
>
> The list of the parents of a configuration can be thought of as a search
> path.  To construct a new configuration the resolver searches for modules
> in the given parent configurations in the order in which they occur in
> the list, and for any given parent it searches its parents recursively in
> the same fashion, before moving on to the next parent in the list.  This
> search order is, thus, not only depth-first but also determined by the
> order of the parents in each list.  The latter property makes it easy to
> tell when one candidate module will shadow another.
>
> To instantiate a new layer from a given configuration, the list of the
> configurations of its parent layers must be identical to the list of the
> parents of that configuration.
>
> The service providers for a module in a given layer are located in the
> same way that the resolver searches for modules, i.e., depth-first and
> in list order.

I am having difficulty adapting our dependency API to it.  We use the 
ability to add a dependency link from a module in one namespace to a 
module in another.  This ability was explicitly added after realizing 
that using a search path made the usage parallel namespaces without name 
mangling impossible.  In JBoss Modules this is accomplished by using a 
module loader (reference)/name (string) tuple for each dependency, but 
AFAICT, because of Jigsaw's reliance on a bytecode image instead of a 
programmatic API to define modules, a similar API wherein we give a 
Layer plus module name to establish the links seems impossible.  Maybe 
we could have a way to reference each "parent" layer by a "relative 
name", which would only be "visible" to the referencing layer, that can 
be used to select which layer a dependency should come from (I think 
we'd need to either support circularity in layers, or allow dependencies 
to unrelated layers, for this to fully work for us though)?  Any other 
suggestions on this are welcome as I'm at a dead end.


-- 
- DML