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