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
