Jakarta Data

Hibernate 6.6 includes a complete implementation of the current Jakarta Data 1.0 Release Candidate. As discussed here, our implementation:

  • is based on compile-time code generation via an annotation processor, enabling unprecedented compile-time type safety, and

  • is backed by Hibernate’s StatelessSession, which has been enhanced especially to meet the needs of Jakarta Data.

This implementation already passes the Jakarta Data TCK, and we have a request for certification pending.

To make use of Hibernate Data Repositories, you’ll need to depend on:

  • our annotation processor, hibernate-jpamodelgen, and

  • the Jakarta Data API, `jakarta.data-api.

For example, in Gradle:

implementation 'jakarta.data:jakarta.data-api:1.0.0-RC1'
implementation 'org.hibernate.orm:hibernate-core:6.6.0.Alpha1'

annotationProcessor 'org.hibernate.orm:hibernate-jpamodelgen:6.6.0.Alpha1'

For more information, please see the brand-new Hibernate Data Repositories documentation.


6.6 also provides a new @ConcreteProxy annotation intended as an improved replacement for the deprecated @Proxy and @LazyToOne annotations. Indicates that lazy references should be instantiated as the concrete type rather than the referenced type.

Consider the following model and data

class Payment { ... }

class CardPayment extends Payment { ... }

session1.persist( new CardPayment( 1, ... ) );

As a simple example -

Payment loaded = session2.getReference( Payment.class, 1 );

Historically, Hibernate would create a lazy proxy for loaded of type Payment. Attempts to cast that reference to CardPayment would result in a casting error. @ConcreteProxy forces Hibernate to resolve the actual, concrete type and create a proxy of that type instead -

CardPayment loaded = (CardPayment) session2.getReference( Payment.class, 1 );
Hibernate will try a number of different ways to determine the concrete type, but may ultimately have to fall back to hitting the database which might have an effect on performance.

This feature works with both Hibernate’s legacy proxy-based laziness and the newer bytecode enhancement laziness.

Back to top