Proposal: #NonHierarchicalLayers

[mark.reinhold at oracle.com]

2016/11/29 18:51:22 -0800, david.lloyd at redhat.com:
> 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:
>>> ...
>>> 
>>> 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.

So, what do you suggest we do?

- Mark