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

David M. Lloyd david.lloyd at redhat.com
Fri May 12 18:08:38 UTC 2017


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?

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?
-- 
- DML


More information about the jigsaw-dev mailing list