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.ll...@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
