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

Reply via email to