In Relation To

The JPQL select new syntax originated in the earliest days of Hibernate, providing a way to package a query projection list into a Java object. This was before Java had generics or record types, so you would use it like this:

Several people have recently asked me how to do "specifications" in Hibernate or in Jakarta Data. I believe this idea comes from Spring Data, where a repository method may be passed a function that applies programmatic restrictions to the query result via the JPA Criteria API.

We’re now seeing a lot of interest in Jakarta Data, along with very positive reactions from the people who’ve already tried it out.

I’m afraid I missed the news that Hibernate 6.6 is now available in Quarkus, and so I’ve been slow of the mark in letting everyone know that Hibernate Data Repositories, our implementation of Jakarta Data, is now fully integrated with Quarkus. 🎉🎉

To start writing repositories, all you need to add is:

Jakarta Data is a new specification for persistence in Java, scheduled for release as part of the EE 11 platform. In a previous post I introduced the basic features of a Jakarta Data repository, with a strong emphasis on how Jakarta Data provides compile-time type safety, enabling static analysis performed by an annotation processor.

This involved moving some information that used to be expressed in procedural code into:

Today we’re going to talk about some more dynamic features of Jakarta Data. You might anticipate that these would come with a loss of type safety, but we’ve found a way to avoid that. The essential ingredient is a static metamodel.

Cross-posted from Substack.

Jakarta Data is a new specification for persistence in Java, scheduled for release as part of the EE 11 platform. Whereas Jakarta Persistence provides a mature and extremely feature-rich foundation for object/relational mapping solutions like Hibernate, Jakarta Data aims to offer a somewhat simplified programming model, but one which is also suitable for use with non-relational databases.