RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v6]

Ioi Lam iklam at openjdk.org
Thu Apr 10 16:07:32 UTC 2025


On Wed, 9 Apr 2025 18:37:15 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

>> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error — see `DifferentSourcesApp.java` from this patch for an example of such app.
>> 
>> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible.
>
> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove findClass, extend explanation comments

test/hotspot/jtreg/runtime/cds/appcds/customLoader/ClassFromClasspath.java line 53:

> 51:         out.shouldContain("unreg CustomLoadee");
> 52:     }
> 53: }

For completeness, I think we should have a more complicated scenario:

- load CustomLoadee in both the app loader and a custom loader
- load CustomLoadeeChild in the custom loader. Its super class should be the one defined in the custom loader

At run time, verify that CustomLoadeeChild is archived and its super class is defined in the custom loader

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2037764057


More information about the hotspot-runtime-dev mailing list