ClassLoader API to look up class files

[Rafael Winterhalter]

This would likely work for those cases. The Byte Buddy plugins for Gradle
and Maven discover today what release version is configured in the compile
step, and uses that version for configuring the class file locators that it
can configure. If a release version is for example set to Java 17, the
class file locators would discover MR class files for Java 17 on both a
version 17 and a version 21 VM, where possible. Jar files are then
initialized using this version, and the same goes for reading from folders.
If I could supply a version to a URLClassLoader, too, I would also set that
version and could supply URLs to it as it is done today. To some degree,
those who implement their custom class loaders would anyways be responsible
to implement such a mechanism for those. Mainly I was wondering if the API
should be standardized via a method, but your suggested approach would of
course work, too, in practice.

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

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