GraalVM native image fails at run time due to NoClassDefFoundError

[AyushChaubey]

I am using a third party library that uses ByteBuddy. The native image is created successfully but fails at run time with below exception -

java.lang.NoClassDefFoundError: Could not initialize class net.bytebuddy.implementation.bind.MethodDelegationBinder$AmbiguityResolver
        at net.bytebuddy.implementation.MethodDelegation.withDefaultConfiguration(MethodDelegation.java:606)

Fixes attempted:
I have used GraalVM tracing agent , followed suggestions recommended here and here. After following these suggestions, I get a different error:

Defining a class from new bytecodes at run time is not supported Class XYZ... with hash a35588c was not provided during the image build

Can you please help on how to proceed here.

Thanks

[raphw]

Are you using a random naming strategy? Likely, some byte code is changed during prerun and compile?

[AyushChaubey]

Thanks for your reply. In the library code, name is not passed for the subclass. I added the name to the dynamic type. I still get the same error but with the name of the dynamic type when I run the native image.

Exception:
Defining a class from new bytecodes at run time is not supported. Class XYZ with hash 07e29f719685ecf5d1653a0 was not provided during the image build. Please see BuildConfiguration.md.."

Below is the code snippet from the library:

val withBinders = MethodDelegation.withDefaultConfiguration()
                .withBinders(Pipe.Binder.install(Forwarder::class.java))
                .to(MappedBatchLoaderWithContextInterceptor(original, name, meterRegistrySupplier.get()))
            ByteBuddy()
                .subclass(MappedBatchLoaderWithContext::class.java)
                .name("XYZ")
                .method(ElementMatchers.named("load"))
                .intercept(withBinders)
                .make()
                .load(javaClass.classLoader)
                .loaded
                .getDeclaredConstructor()
        }.newInstance()

[raphw]

I assume that there is still some randomness and hash 07e29f719685ecf5d1653a0 is not part of the generation. Could you check the generated JSON file for what hash is recorded?

Can you check what GraalImageCode.getCurrent() returns? You could try setting org.graalvm.nativeimage.imagecode to agent what activates some sensitive defaults.