<div dir="auto"><div dir="ltr"><div>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 manifest. This is so rarely the case that it has not played a big role in performance tests. And the file lookups are cheapish.</div><div><br></div><div>For an agent, however, the question is harder. An agent can only query classes or resources from a class loader. Classes are often off limit as it should avoid loading classes what often results in circularities. That's why class files are loaded as resources. To make things worse, a class loader can represent about anything, so the costs are unknown.</div><div dir="auto"><br></div><div dir="auto">Therefore, even if the class loader preindexed Multi-Release versions of classes to load, this would not automatically solve the issue for reading class files as resources.</div><div dir="auto"><br></div><div dir="auto">If the internal mechanism for multi-release jars was improved, I would therefore hope that this fast-path access is exposed somehow via an API as the one I suggested.</div><div dir="auto"><br></div><div dir="auto">With the manual iteration over possible names on the other side, I can see that this currently slows down the agent around 10% on a regular app, compared to ignoring multi release jars from agents.</div><div dir="auto"><br></div><div dir="auto">Thanks, Rafael</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am So., 22. Sept. 2024 um 09:46 Uhr schrieb Alan Bateman <<a href="mailto:alan.bateman@oracle.com" target="_blank" rel="noreferrer">alan.bateman@oracle.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 21/09/2024 22:14, Rafael Winterhalter wrote:<br>
> Hello,<br>
> It is a quite common need for Java agents to resolve class files for <br>
> Java classes by their name. Normally, this is done by requesting a <br>
> resource from the class loader.<br>
<br>
I agree that the scalability issue with MR JARs deserves attention. JEP <br>
238 pre-dates the 6 month cadence where we now add two additional <br>
versions to search each year. I don't think this issue is really <br>
anything to do with Java agents or the ClassLoader API, instead this is <br>
about the JarFile implementation. Some experiments needed but it may be <br>
more efficient to find and cache the names of the entries that are <br>
versioned, and avoid looping through the versions altogether.<br>
<br>
-Alan<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</blockquote></div>