RFR: 8343427: Class file load hook crashes on archived classes from multi-release JARs

[Ioi Lam]

On Wed, 20 Nov 2024 00:37:25 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Currently, when retrieving a ClassFileStream during runtime, we call into the zip library to retrieve the stream based only on a class name. This doesn't work well if the class is in a multi-release jar under a versioned directory such as `META-INF/versions/9/Foo.class`. To address this issue, this change calls the java api `ClassLoader.getResourceAsStream()` to retrieve the stream.
> 
> Passed tiers 1 - 4 testing.

Code change looks good. One comment on the test.

test/hotspot/jtreg/runtime/cds/appcds/jvmti/CFLH/MultiReleaseJars.java line 151:

> 149:         // create multi-version.jar which contains Main.class, Foo.class and Bar.class.
> 150:         // Foo.class has only one version: base version 9.
> 151:         // Bar.class has two versions: base version 9 and default version.

Since there's no default version for Foo, does the class loader try to get the highest version (9 in this case) that's the same or below the current  JDK's version? I think such a comment in the test case would be helpful.

Also, perhaps the test should look like this:


     META-INF/versions/9/Foo.class
     META-INF/versions/11/Foo.class


where the different Foo classes print a different string. We should assert that we get version 11 instead of 9.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22262#pullrequestreview-2449466092
PR Review Comment: https://git.openjdk.org/jdk/pull/22262#discussion_r1850836615