Proposal: #NonHierarchicalLayers

[David M. Lloyd]

On 11/29/2016 06:10 PM, mark.reinhold at oracle.com wrote:
> 2016/11/22 13:23:34 -0800, david.lloyd at redhat.com:
>> On 11/21/2016 03:56 PM, mark.reinhold at oracle.com wrote:
>>> ...
>>>
>>> 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
>> problem.
>>
>> I don't think we need it to work the exact same way, but we need some
>> equivalent.
>
> If this is how you need resolution to work for your modules then can't
> you write your own resolver to make it so, using whatever additional
> (weak) data structures you need to associate names with layers, class
> loaders, etc., in whatever manner you require?

No, because the input to the resolver is just a name; there's no other 
context to say which layer the module comes from, without some kind of 
name mangling scheme which raises more problems (we ran into exactly 
this issue more than six years ago).  In other words I can require a 
module named "X", but I can't say that I require the module "X" from 
this other layer/namespace; rather I have to flatten out all my 
namespaces in a way that can be mutually resolvable, which means that I 
must ultimately constrain user module names in some weird way.  This is 
not so good when modules refer to one another by name programmatically, 
nor in diagnostic output.

-- 
- DML