In Relation To

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.

A few weeks ago, the GitHub Security Lab reported to the Hibernate team a vulnerability in GitHub Actions workflows used in some Hibernate projects, which could have (indirectly) impacted released artifacts.

Fortunately, that vulnerability wasn’t exploited and all Hibernate releases are perfectly safe.

However, considering the impact an exploit could have had, we thought it would be best to provide some transparency on what happened and how we made sure that Hibernate releases — past, present and future — are safe.

We just published a maintenance release for Hibernate Search: 6.2.3.Final.

This release adds compatibility with OpenSearch 2.11, upgrades -orm6 artifacts to Hibernate ORM 6.2.17.Final, upgrades to Elasticsearch client 8.10.4, and adjusts Jandex index reading for compatibility with Spring Boot 3.2.

We are pleased to announce the release of Hibernate Search 7.0.0.Final.

Compared to Hibernate Search 6.2, this release upgrades its baseline to JDK 11 and Hibernate ORM 6.4, brings compatibility with Elasticsearch 8.10/8.11 and OpenSearch 2.10/2.11, and upgrades to Lucene 9.8.

Hibernate Search 7.0 also brings new features such as a brand-new Hibernate Search BOM, experimental compatibility with Amazon OpenSearch Serverless, compatibility with Hibernate ORM’s discriminator-based multi-tenancy, and other bugfixes and improvements.

We just published a new candidate release for Hibernate Search: 7.0.0.CR2.

This release upgrades to the recently released Hibernate ORM 6.4; as this upgrade implies dropping compatibility with Hibernate ORM 6.3, it was deemed a big enough change to warrant a second candidate release. 7.0.0.CR2 also contains a few bugfixes and improvements; see below for more information.

We just published a new candidate release for Hibernate Search: 7.0.0.CR1.

This release brings in particular compatibility with Hibernate ORM’s discriminator-based multi-tenancy, compatibility with Elasticsearch 8.10 and OpenSearch 2.10/2.11, an upgrade to Hibernate ORM 6.3.1.Final, an upgrade to Lucene 9.8, some Maven artifact renamings, and other bugfixes and improvements.

We just published a maintenance release for Hibernate Search: 6.2.2.Final.

This release mainly adds compatibility with Elasticsearch 8.10 and OpenSearch 2.10, upgrades to Hibernate ORM 6.2.9.Final for -orm6 artifacts, upgrades to Elasticsearch client 8.10.2, Jackson 2.15.2 and Avro 1.11.3, deprecates the ~ operator in regexp predicates, and fixes several bugs.

We just published a maintenance release for Hibernate Search: 6.2.1.Final.

This release mainly upgrades to Hibernate ORM 6.2.7.Final for -orm6 artifacts, upgrades to Elasticsearch client 8.9.0, adds compatibility with Elasticsearch 8.9 and OpenSearch 2.9, and fixes several bugs.

We are pleased to announce the release of Hibernate Search 6.2.0.Final.

This release brings in particular a new standalone POJO Mapper, mapping of classes/records to projections using @ProjectionConstructor, highlighting, Elasticsearch schema export, and more bugfixes and improvements.

6.2.0.Final also includes compatibility with Elasticsearch 8.8 and OpenSearch 2.8, as well as an upgrade of -orm6 artifacts to Hibernate ORM 6.2.

We just published Hibernate Search 6.2.0.CR1, a candidate release of the next minor version of Hibernate Search.

This release brings in particular a new excludePaths filter for @IndexedEmbedded, and includePaths/includeDepth/excludePaths filters for @ObjectProjection.

6.2.0.CR1 also includes compatibility with OpenSearch 2.8, an upgrade to Hibernate ORM 5.6.15.Final, an upgrade of -orm6 artifacts to Hibernate ORM 6.2.5.Final, and other bugfixes and improvements.