Proposal: #NonHierarchicalLayers

[mark.reinhold at oracle.com]

2016/11/21 7:17:14 -0800, david.lloyd at redhat.com:
> On 10/31/2016 03:22 PM, mark.reinhold at oracle.com wrote:
>> ...
>> 
>> 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.
>> 
>> ...
> 
> 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.

You can construct `java.lang.module.ModuleDescriptor` objects via the
API, and then use those to configure layers; you don't always need a
`module-info.class` file.

Layers don't have names, but if you're using the approach I suggested
for OSGi [1] then it shouldn't matter, since every JBoss module will be
in its own layer.  (If you really do need to give layers separate names
then you could do so in a `WeakHashMap` that you maintain on the side,
and have your resolver refer to that.)

- Mark


[1] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-October/000410.html