ClassLoader API to look up class files

[Rafael Winterhalter]

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.

Am Di., 24. Sept. 2024 um 15:23 Uhr schrieb Alan Bateman <
alan.bateman at oracle.com>:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240924/c1af1778/attachment.htm>