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
