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
