On Thu, 10 Apr 2025 16:01:20 GMT, Ioi Lam <ik...@openjdk.org> wrote: >> Currently we have some restrictions if`-Djava.system.class.loader=` is >> specified >> >> - we disable full module graph archiving: >> https://github.com/openjdk/jdk/blob/0e223f1456c14efdb423595bee3444d5e26db7c6/src/hotspot/share/cds/cdsConfig.cpp#L286 >> - we disable loading archived classes for platform and system loaders: >> https://github.com/openjdk/jdk/blob/0e223f1456c14efdb423595bee3444d5e26db7c6/src/hotspot/share/cds/filemap.cpp#L1874-L1886 >> >> I think we should extend this limitation further (in a separate issue) >> >> - At dump time, dump only boot classes (no platform, system or unregistered) >> - At run time, load only boot classes (no platform, system or unregistered) >> >> I filed [JDK-8354315](https://bugs.openjdk.org/browse/JDK-8354315) > > In the current JDK (with or without this patch), in your scenario, I think > the name "S" will be printed twice with two different IDs. If a Child class > named "C" is loaded by a custom loader, it will refer to one of the IDs. > Depending on the order of loading, it might refer to the first or the second > ID. > > During dump time, we will try to load this class twice, but both attempts > will result in the same class (defined by the user-defined system class > loader). When resolving the unregistered class, using either ID will give you > the correct super class ... > > Anyway, this seems too fragile. I think we should fix > [JDK-8354315](https://bugs.openjdk.org/browse/JDK-8354315) before integrating > this patch. Or, maybe we can include the fixes of that bug in this PR as well > (and then close that bug as a duplicate of this one). What do you think?
In my scenario I actually meant that <S, AppL> is in the class list while <S, SysL> is not but it doesn't matter much, the incorrect one will be loaded any way. Since the new implementation will behave the same as the existing one in this aspect I think it is OK to fix JDK-8354315 separately. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24223#discussion_r2042346769
