I am having similar issues like this one here [HHH-13242] - Hibernate JIRA that is marked as fixed but not sure why. We had custom ByteCodeProvider with hibernate5 but when we moved to hibernate6 then our provider is just being ignored. Seems like this code in EntityRepresentationStrategyPojoStandard class
final BytecodeProvider bytecodeProvider = Environment.getBytecodeProvider();
is not allowing to use custom byte provider. When this is changed to
final BytecodeProvider bytecodeProvider = creationContext.getBootstrapContext().getServiceRegistry().getService(BytecodeProvider.class);
then our custom bytecode provider is used and works as expected.
What is proper way to configure custom ByteCodeProvider in Hibernate6?
It’s the first time I hear of anyone actually being brave enough to maintain a custom BytecodeProvider; indeed I don’t think it’s currently configurable - I have it on my wishlist for things to improve sometime soon to remove the global environment settings; that’s why these methods are marked as deprecated. Haven’t had a chance to work on it but I appreciate the existence of such system properties require some clarifications.
I’ll try to find some time to remove the misleading properties; we can then also take in consideration to allow integrating a custom one.
Could you give me an idea of why you need a custom implementation?
Ideally I’d want to evolve this in small steps:
Remove the static & global aspects, allowing only a regular configuration property to set either “bytebuddy” or “none”. Allow overrides to happen via a ServiceInitiator.
Move the ByteBuddy enhancer into a separate jar, making it optional.
(Optionally, pending your feedback) Allow to drop in a different implementation instead of the ByteBuddy based implementation.
You might not have to give up on it: we might re-introduce the capability if there’s good reasons but if we can have your need covered in a simpler way that might be preferrable.
What do you mean by “compile time proxy”? Are these different from the build time enhancers we already provide?
Thanks for the work, We currently also have a related issue…
Our application has around 500 entity classes, And after upgrading from hibernate 5.2 to the latest (Currently 7.1 though the issue has persisted through all later versions), The Session factory initialization time increased to 4+ minutes (From the previous under 1 minute)…
We noticed that as we reduce on the entities, The associated initialization time goes down too, Which points to (suspectingly) byte code enhancement and proxy generation…
As documented, Previous versions used javassist while these laters are using bytebuddy, Which is turning out to be slower - As you can imagine, In a desktop application you can’t really display a splash screen for 4+ minutes waiting for the Session factory to initialize…
What we can’t test now is trying to switch back to javassist since the hibernate.bytecode.provider is now totally ignored, Our request is to support this setting since different applications have different requirements, That’s the point of the ByecodeProvider contract…
Different developers can always come up with more efficient implementations and it’s just ‘not wise’ to lock them out, Bytebuddy can always be the default BUT there should be a way to switch basing on one’s application requirements…
BytecodeProvider was turned into a Java ServiceLoader contract via HHH-17643 in 6.2.21, so you can plug your own version if you want to maintain it. The Hibernate Team will only focus on one implementation.
Note that there are many potential reasons for why an application might start up slower. A lot has changed in the bootstrap of Hibernate ORM, so this could very well be due to something else.
If application startup time is important to you, you should consider doing the bytecode enhancement at build time or switch over to Quarkus directly, which does that out of the box and also allows you to compile to a native image, further lowering the startup time into the range of milliseconds.