ClassLoader API to look up class files

[Eirik Bjørsnøs]

On Sat, Sep 21, 2024 at 11:15 PM Rafael Winterhalter <rafael.wth at gmail.com>
wrote:

> Hello,
> It is a quite common need for Java agents to resolve class files for Java
> classes by their name. Normally, this is done by requesting a resource from
> the class loader. So if a class:
>
> pkg.SampleClass
>
> is requested, the agent calls
> ClassLoader.getResourceAsStream("pkg/SampleClass.class"). This normally
> works well, with a few exceptions where class loaders do not implement
> lookup.
>
> However, with multi-release jars this is less reliable. In theory, on a
> Java 23 VM I would need to request all from:
>

Rafael,

URLClassLoader::getResource already resolves the versioned class file
entry, that is URLClassLoader::getResource will return the URL for
"META-INF/versions/21/HelloWorld.class" when given the parameter
"HelloWorld.class" with a multi-release JAR on the class path.

So since you're re-implementing version lookup yourself, I assume what you
are experiencing here must be some third-party JAR-backed custom
classloader overriding ClassLoader.findResource without properly taking
versioned entries into account, right?

If that's the case, then the class file loaded would probably not be
versioned correctly either, right? Also, if people can't override
ClassLoader.findResource to support versioning, then I'd be surprised if
they would override a new API point like getClassFileAsStream correctly.

Perhaps you could expand a bit why you need to implement the version lookup
yourself? Which hole are you mending here?

Cheers,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240922/3fff58c2/attachment-0001.htm>