Request Review: JDK-6479237 (cl) Add support for classloader names

[Alan Bateman]

On 26/10/2016 14:28, David M. Lloyd wrote:

>
> I am not a reviewer.  I have a question though: Does this mean that 
> you have to establish the name of your class loader in the constructor?
Yes, it's named at creation time. The VM uses the name when filling in 
the stack trace, it's not invoking getName to execute arbitrary code 
when doing that.

>
> If so, here's what mainly bothers me about this approach:
>
> - With a new constructor being required, you cannot easily write a 
> class loader which both functions under Java 8 and has a name under 
> Java 9 without resorting to MR JARs
> - The getName() method can be overridden but doing so has no effect on 
> the real name of the class loader
> - ... but you can't make it final or you risk breaking class loaders 
> that already exist
>
> Maybe instead, the "name" field (or other internal mechanism) could 
> somehow be lazily populated by calling getName(), which returns null 
> by default but can be overridden by subclasses?  This way ClassLoaders 
> can function the same way in Java 8 and 9, and just get extra 
> functionality when running under Java 9
Ideally getName would be final but it can't for the reason you noted 
(there is still the risk that someone has a custom class loader with a 
no-arg getName method that is not public or has a different return type 
of course).

-Alan