When dumping a CDS archive using -Xshare:dump, the classlist can contain "unregistered" classes. E.g., for the following classlist:

    java/lang/Object id: 0
    Foo id: 1 super: 0 source: src.jar
    Bar id: 2 super: 1 source: src.jar

Foo and Bar are the unregistered classes (they have the "source:" attribute). At runtime, these classes won't be loaded by the boot/platform/app loaders. Instead, they will be loaded by custom ClassLoaders.

Conceptually, at dump time, we should construct a java.lang.ClassLoader L, such that:

L.loadClass("Foo") -> returns an InstanceKlass F which is defined with src.jar/Foo.class. F's super class should be java/lang/Object.

L.loadClass("Bar") -> returns an InstanceKlass B which is defined with src.jar/Bar.class. B's super class should be F.

Historically, the support for unregistered classes were implemented when we couldn't execute Java code during -Xshare:dump, so we couldn't implement a real ClassLoader. Instead, we would define Bar with the boot class loader. However, when the boot class loader needs to find the super of Bar, we go through a hack because we don't have a real ClassLoader delegation mechanism

https://github.com/openjdk/jdk/blob/d9744f6536076144ff09c4e788a892bdc3d4bacb/src/hotspot/share/classfile/systemDictionaryShared.cpp#L1206

Since JDK-8172218, we are able to execute Java code during -Xshare:dump, so we should implement a real ClassLoader and remove the above hack.