<div dir="ltr"><div>Hello,<br></div><div>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:</div><div><br></div><div>pkg.SampleClass</div><div><br></div><div>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.</div><div><br></div><div>However, with multi-release jars this is less reliable. In theory, on a Java 23 VM I would need to request all from:</div><div><br></div><div>"META-INF/versions/23/pkg/SampleClass.class"</div><div>to <br></div><div><div>"META-INF/versions/9/pkg/SampleClass.class"</div><div>and finally</div><div><div>"pkg/SampleClass.class"</div></div><div><br></div><div>This is of course not scalable. To ease the process, I wanted to suggest to add a method to class loader:</div><div><br></div><div>public InputStream getClassFileAsStream(String name, short version) {</div><div>  return getResourceAsString(name.replace('.', '/') + ".class");<br></div><div>}</div><div><br></div><div>In the default implementation, this would simply fall back to finding the resource in the standard location. However, class loaders could override this method to look up the class file for a class from different locations. Normally, the class loader has better knowledge of the represented class files and can look up multi-release files more efficiently than by iterating over a growing number of locations.</div><div><br></div><div>Is this something that could be considered?</div><div><br></div><div>Thanks! Rafael<br></div></div></div>