Why not multiple modules of the same name in a class loader?

[David M. Lloyd]

On 05/12/2017 02:09 PM, David M. Lloyd wrote:
> On 05/12/2017 01:46 PM, Remi Forax wrote:
>>
>>
>> On May 12, 2017 8:08:38 PM GMT+02:00, "David M. Lloyd" 
>> <david.lloyd at redhat.com> wrote:
>>> This has come up a couple times now and I'm not sure why the rule
>>> exists: why not allow multiple modules with the same name in the same
>>> class loader?
>>
>> module names appear in the stack traces,  it will make life of people 
>> miserable if they have to open several artifacts to find the good one.
> 
> I agree; but, I wasn't looking for moral reasons, I was just curious 
> about the technical constraint (if it even exists; maybe it does not!).
> 
>>> As far as I can tell, there is no way to locate a module by class
>>> loader, and module namespaces are generally already well-governed by
>>> their layer, so from an API perspective at least, it seems like this is
>>>
>>> a harmless scenario (as long as there are no package conflicts,
>>> obviously, but a container generally is able to manage this concern).
>>>
>>> Preventing this does block one potential workaround for the lack of a
>>> ModuleLayer.Controller.addPackage() method, which would be to
>>> supplement
>>> a module's content at run time by defining a new Layer that contains a
>>> module of the same name as the original content within the same class
>>> loader, where the container would then take care of such details as
>>> mutual read/opening and cyclic access.
>>>
>>> So that made me curious: is there some hotspot-internal dictionary that
>>>
>>> I missed, which manages the set of modules within a class loader?
>>
>> take a look to defineModule :)
> 
> I assume you mean Module.defineModule0 -> JVM_DefineModule -> 
> Modules::define_module, which is where I looked.  It seemed to care 
> about the class loader of the module, and about package names, but 
> unless I'm just being blind to this (always a possibility), I don't see 
> anyplace where it cares about what modules are defined to the class 
> loader.  The closest thing I see is the bootstrap code which reads from 
> the jimage, but none of that applies to user ModuleLayers.
> 
> In other words, I find no Map<String, Module>, or its C++ equivalent, at 
> any level in a class loader that would be capable of such enforcement, 
> let alone require it.
> 
> I guess I should do some more testing & tracing to see how this part 
> works; maybe it's actually allowed!

Found it: there's a module table on ClassLoaderData that you get via its 
modules() method.


-- 
- DML