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

[David M. Lloyd]

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!

-- 
- DML