This bug affects only JDK 25. It doesn't affect JDK 24.

It's caused by JDK-8348426, which enables CDSConfig::is_dumping_archive() during the AOT training run (-XX:AOTMode=record).

As a result this code is reached

https://github.com/openjdk/jdk/blob/c8a30c2aaba04c11b70a4f74ee74452250be6e59/src/hotspot/share/classfile/systemDictionaryShared.cpp#L774-L776

bool SystemDictionaryShared::add_verification_constraint(InstanceKlass* k, Symbol* name,
         Symbol* from_name, bool from_field_is_protected, bool from_is_array, bool from_is_object) {
 [...]
      // For non-builtin class loaders, we cannot complete the verification check at dump time,
      // because at dump time we don't know how to resolve classes for such loaders.
      return true; <<<<<<<
    }

This causes VerificationType::is_reference_assignable_from() to skip the actual subtype check:

https://github.com/openjdk/jdk/blob/c8a30c2aaba04c11b70a4f74ee74452250be6e59/src/hotspot/share/classfile/verificationType.cpp#L109-L116

    if (CDSConfig::is_dumping_archive()) {
      if (SystemDictionaryShared::add_verification_constraint(klass,
              name(), from.name(), from_field_is_protected, from.is_array(),
              from.is_object())) {
        // If add_verification_constraint() returns true, the resolution/check should be
        // delayed until runtime.
        return true;
      }
 
====================
Proposed fix: the skipping should happen only when dumping "classic" CDS archive, which uses jdk.internal.misc.CDS$UnregisteredClassLoader for loading non-built-in classes.

In all other cases, when a custom class loader is loading a class X, the loader knows how to resolve any class Y that may be needed in the verification of X.