David M. Lloyd
david.lloyd at redhat.com
Mon Nov 21 15:17:14 UTC 2016
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. 
> 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.
More information about the jpms-spec-observers