I now debugged a bit. Even if I provide my own implementation of the Bytecode Provider in META-INF/service of my application, both the hibernate-core own and my implementations will be loaded due to the complex rules in the org.hibernate.boot.registry.classloading.internal.AggregatedServiceLoader.$ClassPathAndModulePathAggregatedServiceLoader class. And then Byte Buddy crashes the native image. I patched the hibernate-core.jar and replaced the implementation with no op Bytecode Provider manually, and then it worked. Then I added ByteBuddy implementation in the META-INF/services of my own app and then again both Bytecode Providers have been loaded. So I think it’s a bug (it shouldn’t load the Byte Buddy if I override it and it should load only one implementation as otherwise how I can override/disable the default one?). So, please provide a clean way of how I can override the default implementation with no op Bytecode Provider.
I also experimented with GraalVM exclude resourced policies to exclude the default implementation (by simply not including the hibernate-core META-INF/services/org.hibernate.bytecode.spi.BytecodeProvider into the native image), but didn’t have success until now as this file is always there, loads ByteBuddy and crashes in the native image.
Yes, I know that Quarkus, Spring Boot and can do this kind of magic and exchange the provider implementation and the compile time, but I’d like to know how to override it without those frameworks.
By the way, by manually patching described above, I now already have a working application based on Native Image and deployable on AWS Lambda as Custom Runtime. That was a lot of work (see the native image config files and pom.xml) and I’d like to do the last step by correctly overriding org.hibernate.bytecode.internal.none.BytecodeProviderImpl and getting rid of this patching.