ClassLoader API to look up class files

[Alan Bateman]

On 24/09/2024 11:43, Rafael Winterhalter wrote:
>
> Without getting lost in specifics:
>
> Byte Buddy allows to transform classes and to store the transformed 
> state. Increasingly, this is done at build time to reduce start up 
> costs and to support AOT compilation. Java agents are the more common 
> option still, but I notice a shift to build time instrumentation, also 
> because of dynamic attach becoming less accessible. One consequence is 
> that the building JVM might not be of the same version as the 
> executing JVM.
>
> With this in mind, class files are read from either:
> - A folder
> - A JAR file
> - A ClassLoader (getResourceAsStream)
>
> In build tools, the last option is rather uncommon, but it exists. I 
> can only assume that the people that requested this use case have good 
> enough reasons for this (probably because URLs are remote and the 
> logic to fetch them is wired into a loader implementation, I am 
> guessing, though).
>
> If the build plugin now wants to create instrumented versions of class 
> files for a Java 17 JVM, while the build is run on a Java 21 JVM, I 
> can support this for JAR files, for folders, but I cannot fetch the 
> adequate resource when the underlying resource accessor is a class 
> loader. I do not think that I can work around this, or do I overlook 
> something?
>

Tooling that does static instrumentation leads itself to a --release N 
option. Assuming this isn't a training runs of sorts it's hard hard to 
picture a ClassLoader in that environment. How does the build tool now 
what to setup so that it matches the arrangement and visibility of 
runtime? Is it really a ClassLoader or something just locates the class 
bytes in the same way as a ClassLoader at runtime?

-Alan