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