Thank you Sanne. True, usage of org.hibernate.bytecode.internal.none.BytecodeProviderImpl will error by default, thus no potentially already enhanced type won't be able to serve the needs here.

The current approach where frameworks need to plug in their own eg. BytecodeProvider / ProxyFactoryFactory (like Quarkus is doing) can lead to a different experience for users depending on the way they happen to consume hibernate. May this be using hibernate standalone, with quarkus or spring. Currently each framework would have to maintain their own flavor of ProxyFactoryFactory and StandardServiceInitiator<ProxyFactoryFactory> plus all the code to mix them together in order to provide sufficient enough native image experience.

Decoupling the current arrangement with org.hibernate.bytecode.internal.bytebuddy.BytecodeProviderImpl being the default, adding a third option, able to pick up already enhanced/precomputed types would lead to less friction. If there was some API to call that creates the Proxy at build time (which can be invoked by any AOT processing engine or even the hibernate maven/gradle plugins) would allow to include precomputed proxies in the image being discoverable eg. via conventions.

Furthermore, depending on the actual implementation of it, the GraalVM native image analysis could then be optimized so that code paths, that currently lead to the inclusion of ByteBuddy types in the native image, can be cut off, resulting in smaller executables.