On 22/09/2024 17:45, Rafael Winterhalter wrote:
That is only true for Class::getResource which resolves resources relative to the loaded class's class file location. Java agents typically use ClassLoader::getResource(AsStream) as the loaded class is not available in the general case of transforming, and not retransforming, a class. For example, when instrumenting a newly loaded class A in a ClassFileTransformer, it might not be the case that its superclass B is loaded. If class B exists in two versions as part of a multi-release jar file, currently, you need to query the class loader of A as the JVM would do. When loading a class, ClassLoader::findClass respects the multi-release characteristic. But for ClassLoader::getResource, this is not the case. This is why I want to suggest a new method where this is possible, as the intend to resolve a class file is explicit. Currently, you need to iterate as the ClassLoader does not expose any relevant information.
If a URLClassLoader is created with a URL to a JAR file then it should open it as a MR-JAR and getResource should find the .class resources in the versioned section. Are you saying that this doesn't work? If it doesn't work then I think it would be useful to show the getResource(name) output. If the resource is versioned then you end with "!/META-INF/versions/$N/$R". But maybe this is a different type of ClassLoader?
-Alan
