Proposal: #NonHierarchicalLayers

[David M. Lloyd]

On 12/05/2016 06:21 PM, David M. Lloyd wrote:
> On 12/05/2016 05:08 PM, mark.reinhold at oracle.com wrote:
>> 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?
>
> Is it possible to add overloads in ModuleDescriptor.Builder like this:
>
>   // Export to the named module in the given layer
>   ModuleDescriptor.Builder exports(String pn, String target, Layer
> targetLayer);
>
>   // Add dependence on module with the given name in the given layer
>   ModuleDescriptor.Builder requires(String mn, Layer layer);
>   ModuleDescriptor.Builder requires(Set<Modifier> mods, String mn, Layer
> layer);
>
> I think that's all that's necessary.

I'm currently looking into defining modules with no dependency 
information, and adding all the exports after the fact: that might be a 
solution to this.

-- 
- DML