Proposal: #NonHierarchicalLayers

David M. Lloyd david.lloyd at
Tue Nov 22 21:23:34 UTC 2016

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

No, I was just suggesting a solution to the problem I see.

To degenerate the problem to the simplest case: I may have to layers, A 
and B, which are unrelated and both contain a module X.  I may need the 
module X in one layer to have a dependency on the module X in another 
layer.  Unless there's new code I haven't seen, each dependency is 
expressed by name only, therefore this is impossible.  Whereas in our 
system, a dependency is a tuple of (module loader, module name), 
allowing arbitrary weaving of modules from different name spaces with no 

I don't think we need it to work the exact same way, but we need some 

More information about the jpms-spec-observers mailing list