In Relation To

When we decided to build Hibernate Accessor, our primary goal was simple — we wanted raw, hand-written field access speed with as little runtime overhead as possible and bytecode that the JIT can optimise as far as it can.

As we discussed in the previous part of this series, existing JDK abstractions like MethodHandle and LambdaMetafactory fall short for the dynamic runtime requirements of Hibernate projects. Hence, the path forward was supposedly clear — emit the bytecode we want, not the bytecode we are given.

Now, how would we do that ? Where should we start ? And what hidden surprises await us behind that codegen curtain ?

Every time we benchmark and profile one of our Hibernate projects for whatever reason we can always count on our good old friend — reflection — to show up and say hello.

Hibernate projects work with user-defined Java objects. Hence, all these projects need a way to read and update fields and create new instances of such objects. Java Reflection can do this, but is it always the best approach? As most abstractions there are downsides to it. It can introduce some unnecessary performance overhead and extra checks/behaviour that may not be required for our use cases. It can also make performance flamegraphs noisier (that is where we have seen it!). Each project is still left to deal with JPMS access rules and member access conventions on its own. On top of that, reflection requires extra configuration for native builds. On the other hand, reflection is a standard JDK API, is simple enough on the surface, and has stood the test of time. Can we do any better than that?

This is certainly not a new problem, and it is not the first time we asked these questions of ourselves. Over the years, each project was experimenting within their own codebases in isolation to find a suitable approach. Solutions we came up with were either partial, not easily shareable with no simple way of plugging an alternative implementation, and some just not suitable because they were tailored to work with certain access patterns. Yes, this matters because the best-performing approach depends on the task — for example, traversing a validation graph versus loading database results into entities.

In an attempt to solve this, we started Hibernate Accessor — a unified state access engine designed to eliminate unnecessary reflection overhead and provide solution for specific access patterns across the whole Hibernate project portfolio.

In this series we will take you through the journey starting from giving you an idea why existing JDK APIs do not solve the problem for us, then walk you through hidden surprises and tricks of bytecode generation and JPMS as well as some of its shortcomings. We will show you how and what we have benchmarked to select a good default all-rounder solution, and finishing the series by exploring what shifting code generation to the build time can achieve and how do we plan to leverage that.

We recently announced the release of Hibernate Validator 9.1.0.Alpha2, where we hinted that this new series focuses on performance improvements.

The first release candidate for Hibernate ORM 6.6 has already been released, and a final version will be available very soon. In today’s blog post, I’m going to delve into a feature that has been requested for a long time but has never made it into our framework until now: Embeddable Inheritance.

Hibernate ORM version 6.6 is already available in Alpha version, and a final release will follow soon. In today’s post we’re going to dive into one of the new features that comes with this version, the new @ConcreteProxy annotation.

Hibernate ORM version 6.5 already received a couple candidate release versions, and a final release will follow shortly. This post highlights one of the improvements that comes with this version: efficient retrieval of non-identifier database generated values.

Hibernate ORM version 6.2.0.Final is around the corner, and the following post tries to shed some light on one of the new features that comes with that release.

Hibernate ORM version 6.2.0.Final is around the corner, and the following post tries to shed some light on one of the new features that comes with that release.

Hibernate ORM version 6.2.0.Final is around the corner, and the following post tries to shed some light on one of the new features that comes with that release.

Hibernate ORM version 6.2.0.Final is around the corner, and the following post tries to shed some light on one of the new features that comes with that release.