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
cla
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 represent
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
relev
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
opti
When the ClassLoader API is used in build plugins, this often serves as a
fallback to non-standardized class storage where the retrieval
implementation is bound to the ClassLoder API. I would have to guess but I
would not assume that many of them use a JarInputStream as a backing
mechanism. By my e
On Tue, Sep 24, 2024 at 1:44 PM Eirik Bjørsnøs wrote:
> Does the class loader in question return JAR-form URLs? If that's the
> case, you could use JarURLConnection.getJarFile() and use getInputStream to
> get the versioned resource of choice:
>
If you also want to offload the version lookup log
On Tue, Sep 24, 2024 at 12:44 PM Rafael Winterhalter
wrote:
> Without getting lost in specifics:
>
It is also possible to get very lost by lacking specifics :-)
> 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
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 instrumen
On 23/09/2024 20:35, Rafael Winterhalter wrote:
So I tracked down the discrepancy to a changing default for
URLClassLoader compared to JarFile. URLClassLoader resolves resources
to the "versions" folder for Java 9 and later, even without code
changes. This is not the case for JarFile where the
So I tracked down the discrepancy to a changing default for URLClassLoader
compared to JarFile. URLClassLoader resolves resources to the "versions"
folder for Java 9 and later, even without code changes. This is not the
case for JarFile where the relevant version needs to be passed to a new
constru
On 22/09/2024 17:45, Rafael Winterhalter wrote:
That is only true for Class::getResource which resolves resources
relative to the loaded class's class file location. Java agents
typically use ClassLoader::getResource(AsStream) as the loaded class
is not available in the general case of transfor
On Sun, Sep 22, 2024 at 6:46 PM Rafael Winterhalter
wrote:
Sorry, still not sure I understand the scenario..
That is only true for Class::getResource which resolves resources relative
> to the loaded class's class file location.
>
Class:getResource simply adds the package name prefix and calls
In Byte Buddy, class files are typically looked up from a Java agent or a
build tool plugin. The underlying abstraction is a ClassFileLocator. In a
build tool, the locator is typically based on jar files or folders. Here,
the locator can determine that a jar or folder is multi-release by a
possible
That is only true for Class::getResource which resolves resources relative
to the loaded class's class file location. Java agents typically use
ClassLoader::getResource(AsStream) as the loaded class is not available in
the general case of transforming, and not retransforming, a class. For
example,
On 22/09/2024 16:42, Eirik Bjørsnøs wrote:
:
Alan,
JarFile.getVersionedEntry no longer searches the full historical
version range, but only tries the specific versions actually present
in the JAR file. So this probably isn't as bad as it sounds, assuming
most multi-release JARs only have e
On Sat, Sep 21, 2024 at 11:15 PM Rafael Winterhalter
wrote:
> Hello,
> It is a quite common need for Java agents to resolve class files for Java
> classes by their name. Normally, this is done by requesting a resource from
> the class loader. So if a class:
>
> pkg.SampleClass
>
> is requested, t
On Sun, Sep 22, 2024 at 12:14 PM Alan Bateman
wrote:
> On 21/09/2024 22:14, Rafael Winterhalter wrote:
> > Hello,
> > It is a quite common need for Java agents to resolve class files for
> > Java classes by their name. Normally, this is done by requesting a
> > resource from the class loader.
>
>
On 21/09/2024 22:14, Rafael Winterhalter wrote:
Hello,
It is a quite common need for Java agents to resolve class files for
Java classes by their name. Normally, this is done by requesting a
resource from the class loader.
I agree that the scalability issue with MR JARs deserves attention. JE
18 matches
Mail list logo
