ClassLoader API to look up class files

[Alan Bateman]

On 24/09/2024 17:47, Rafael Winterhalter wrote:
> Byte Buddy attempts to avoid class loading during build 
> instrumentation, as this might have side-effects when types are 
> loaded, and described, using the reflection API. Therefore Byte Buddy 
> parses class files itself and offers its own representation. 99.9% of 
> users will be able to provide all relevant class files by pointing to 
> a jar file or a folder with classes, and Byte Buddy will treat this as 
> a form of class path to describe the dependency tree to the build time 
> instrumentation, without loading any classes. As an option for the 
> reminding 0.1%, dependencies can also be provided using a ClassLoader. 
> A case I have encountered more than once is that a custom ClassLoader 
> generates classes on demand if queried. To support this, Byte Buddy 
> then queries the ClassLoader for ".class" files also, without 
> processing a jar file or folder directly.
>
> As of today, I have no way to tell the class loader that the target 
> version of the build plugin is for example Java 17, and that I want 
> the Java 17 version of a class file. I can query for META-INF/versions 
> 8-17 to see if there is a class file for that name (rather 
> inefficient). But if the build is run on a Java 21 JVM and there is a 
> META-INF/versions/21 version of a class, the Java 17 "original" class 
> file is not available to me. This is why I was wondering if there 
> should be a method to query a resource "as if" it was requested for a 
> particular version that is not the current JVM (or 
> JarFile-constructor-supplied) version.
>
> Does this describe my problem better? I understand that this really is 
> an edge case. Then again I think this is a legitimate problem that 
> should be solvable. And with a shift towards build-time 
> instrumentation and likely growing adoption of MR JAR files, I would 
> of course want to solve this in Byte Buddy, if given the opportunity.
>
Thanks, I think the scenario is a much clearer now but I don't think 
adding a method to ClassLoader to aid this scenario is the right thing 
to do.

Instead, this feels like a ClassLoader implementation that is created 
with a Runtime.Version and excels at serving up resources. That's 
effectively what you get with using JDK tools like jdeps with the 
--multi-release N option. That ClassLoader implementation would create 
JarFiles with the Runtime.Version so it will locate the resources in MR 
JARs for that version. If you had such a ClassLoader implementation, 
could you fit into the build steps?

-Alan