If a class with the name "Foo" is defined during the AOT training run using a native method like this:

#include <jni.h>

JNIEXPORT jclass JNICALL
Java_JNIDefineClassApp_nativeDefineClass(JNIEnv* env, jclass clazz /*unused*/,
                                         jstring className, jobject classLoader, jbyteArray bytecode) {
    const char * classNameChar = (*env)->GetStringUTFChars(env, className, NULL);
    jbyte * arrayContent = (*env)->GetByteArrayElements(env, bytecode, NULL);
    jsize bytecodeLength = (*env)->GetArrayLength(env, bytecode);
    jclass returnValue = (*env)->DefineClass(env, classNameChar, classLoader, arrayContent, bytecodeLength);
    (*env)->ReleaseByteArrayElements(env, bytecode, arrayContent, JNI_ABORT);
    (*env)->ReleaseStringUTFChars(env, className, classNameChar);
    if (!returnValue) {
        printf("ERROR: DefineClass call returned null by some reason. Classloading failed.\n");
    }
    return returnValue;
}

Such a class should be excluded from the AOT configuration file, because it does not come from supported locations (JDK modules file, classpath or modulepath).

However, we have a bug where this class is incorrectly included in the AOT configuration file. As a result, when creating the AOT cache using this AOT configuration file, we get an error like this:

[0.498s][error][aot ] java.lang.NoClassDefFoundError: Foo
[0.498s][error][aot ] Please check if your VM command-line is the same as in the training run
[0.498s][error][aot ] An error has occurred while writing the shared archive file.
[0.498s][error][aot ] Unexpected exception, use -Xlog:aot,exceptions=trace for detail