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.

Hibernate Reactive 4.2.1.Final is now available.

Hibernate Reactive 4.2.1.Final is compatible with Hibernate ORM 7.2.0.Final, and Vert.x SQL client 5.0.2.

If you need a Hibernate Reactive version compatible with older Hibernate ORM releases or Vert.x releases, you can find a compatibility matrix on the Hibernate website.

Hibernate Reactive 3.2.1.Final is now available.

Hibernate Reactive 3.2.1.Final is compatible with Hibernate ORM 7.2.0.Final, and Vert.x SQL client 4.5.

If you need a Hibernate Reactive version compatible with older Hibernate ORM releases or Vert.x releases, you can find a compatibility matrix on the Hibernate website.

Today, we published a new maintenance release of Hibernate ORM 6.4: 6.4.3.Final

Today, we published a new maintenance release of Hibernate ORM 6.4: 6.4.2.Final

Hibernate ORM 6.4.0 has just been released. Simultaneously, 6.3.2 has also been released.

6.4 adds some cool new features, in addition to many improvements and fixes.

Today, we published a new maintenance release of Hibernate ORM 6.3: 6.3.1.Final and ORM 6.2: 6.2.9.Final.

Today, we published a new maintenance release of Hibernate ORM 6.1: 6.1.7.Final.

Today, we published a new maintenance release of Hibernate ORM 5.6: 5.6.15.Final.