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

[Remi Forax]

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.

and if later the VM is able to isolate un-exported packages, it will be a real mess because at worst, you will have to follow all stack elements to find the class you want.


>
>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 :)

Remi

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.