Since JDK-8348426, the following check becomes invalid

https://github.com/openjdk/jdk/blob/03dca0323d79ef5fb1c8ee1152667e2188fa5e01/src/hotspot/share/classfile/classLoader.cpp#L1258-L1262

    // A class from a named module from the --module-path. Ensure the index is
    // within the --module-path range before assigning to the classpath_index.
    if ((pkg_entry != nullptr) &&
        !(pkg_entry->in_unnamed_module())
         && cl->from_module_path()) {
            classpath_index = i;
     }

If a class exists in a JAR file under --module-path, but a class X of the same name is loaded by a custom class loader, the "classpath_index = i" line is executed. Subsequent code will end up incorrectly categorizing X as loaded by the "boot" loader.

The symptom can be seen in the log file of the test case (in the PR of this bug)

[0.438s][debug ][cds,class] klasses[ 1079] = 0x0000000800329ec0 boot com.test.Foo

The correct log should be

[0.438s][debug ][cds,class] klasses[ 1079] = 0x0000000800329ec0 unreg com.test.Foo

Because of this mis-categorization, we will run into an error in the assembly phase:

Reading AOTConfiguration AOTCacheSupportForCustomLoaders.aotconfig and writing AOTCache AOTCacheSupportForCustomLoaders.aot
[0.093s][info][cds] Rewriting and linking classes ...
[0.114s][error][cds] java.lang.NoClassDefFoundError: com/test/Foo
[0.114s][error][cds] Please check if your VM command-line is the same as in the training run
[0.114s][error][cds] An error has occurred while writing the shared archive file.
[0.114s][error][cds] Unexpected exception, use -Xlog:cds,exceptions=trace for detail