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

[David M. Lloyd]

On 10/26/2016 08:52 AM, Alan Bateman wrote:
> 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.

I was afraid that might be the case.  I guess it is impractical 
(performance-wise) to use a StackWalker to do this in Java-space 
instead?  The advantage being that in that case you can just retrieve 
the class loader (and thus its name) off of the class of each frame.

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

Yeah, that's not great.  Could be mitigated by having a static 
ClassLoader.getNameOf(classLoader) method I guess, though this doesn't 
really help the concern I already stated (just the opposite in fact)...

Some background is in order I guess.  I've been reworking a couple of 
our projects to support both Java 9 and Java 8, using MR JARs and also 
without MR JARs.  In the MR JAR case it's been easiest (so far) to push 
off the JDK-version-specific stuff into a nonpublic "JDKSpecific" class 
which gets replaced under Java 9.  However, because the ClassLoader 
change requires a new constructor to be called, I actually have to put 
the whole ClassLoader implementation into the MR supplement, which is 
pretty clunky at best and might introduce some tricky build difficulties 
at worst.

Basically I'm hoping there could be some solution which doesn't involve 
requiring a new constructor to be called, so I can avoid having to do this.
-- 
- DML