ClassLoader API to look up class files

Alan Bateman alan.bateman at oracle.com
Tue Sep 24 06:28:22 UTC 2024


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 relevant version 
> needs to be passed to a new constructor that is introduced in Java 9, 
> requiring code changes.

A lot of the direct usages of JarFile will be tools rather than custom 
class loaders so it was important that it be opt-in for this cohort. The 
exploration into compatibility and migration for MR JARs was 8-10 years 
ago. Looking at it now I don't think other defaults would have worked.

In the API docs "Implementation Note" you'll see that system property 
jdk.util.jar.enableMultiRelease can be set to "force" as a migration 
aid, maybe it will be useful here.



>
> This creates a new problem to me however: I can look up a 
> META-INF/versions resource in a multi-release jar, when using a class 
> loader, no matter the JVM version. I can however not look up the 
> original "non-META-INF" resource. I have been browsing the source 
> code, and this seems to be impossible, is that right? This again 
> brings me back to my original suggestion. Should there be a method in 
> ClassLoader (and JarFile) that allows locating a resource for a given 
> version? In code instrumentation tools, mostly for build, but also for 
> agents, it can be rather essential to query class file stores for 
> specific versions.
>
> I learned in the process that multi-release jars can contain anything, 
> not only classes. Therefore, I wonder if adding a method like the 
> following would be reasonable?
>
> public InputStream getResourceAsStream(String name, Runtime.Version 
> version) {
>   return getResourceAsStream(name);
> }
>
> This would allow MR-aware class loaders an option to expose resources 
> independently of the current JVM version.
>
ClassLoader is abstracted away from where the resources are loaded from. 
So a different level from MR JARs.

I think it would be useful for the discussion if you could say more 
about this custom class loader is. Does it extend URLClassLoader, does 
it use JarFile directly, ... From the mails so far it sounds like there 
is something in the picture that is "MR JAR unaware" but it reading 
resources from a MR JAR. It sounds like some operations are locating 
resources in the base section and some in the versioned section.

-Alan


More information about the core-libs-dev mailing list