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
