In Relation To

Today—​or rather, late last night—​we released Hibernate ORM 7, which includes the latest version of Hibernate Data Repositories. We’ve also released Hibernate Validator 9.

This is the first production-ready version of our platform available entirely under the Apache Software License. (Yes, that includes Envers!) And it’s the first version of our platform to fully support Jakarta EE 11.

Compared to the massive reengineering effort that went into Hibernate 6, this release is much more incremental, and most users should experience a smoother migration. But, as befits a major release, we’ve removed some deprecated functionality. So let’s get the bad news out of the way first.

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.

I often find myself in the slightly uncomfortable position of playing gatekeeper. Someone comes along with some good idea, and I have to be the asshole who pulls their idea apart, or ultimately winds up saying "no". I’m acutely aware that this often leaves the impression of me being resistant to new ideas, or change, or whatever, but people who know me well know this isn’t the case. So let’s think about why gate-keeping is necessary, and what it means to do it well.

Let me begin by saying that good ideas are cheap. On an average week I have one or two good ideas about how to improve Hibernate, or Jakarta Persistence, or Jakarta Data, and when I’m in one of those periods where I’m really focussed on this stuff — which means I’m thinking about persistence 24 hours a day, including when I’m eating and sleeping, work/life balance a la mierda — it’s more like ten good ideas a day.

Naturally, upon reflection, it turns out that nine out of ten of my "good" ideas are actually rubbish. Generously, one in ten of the remaining tenth ultimately get implemented in Hibernate. And of these survivors, I propose many fewer than a tenth for inclusion in the Persistence or Data specifications. Some of those proposals get knocked down by the rest of the group, or are transformed into something almost unrecognizable. That is to say, I need to generate thousands of ideas to get one new feature into the platform, and the process from "idea" to specification change typically takes years, or in extreme cases even decades (looking at you, StatelessSession).

The fourth beta release of Hibernate 7 is now available.

Along with many bugfixes and minor improvements, this release features the following enhancements:

Last week, Jeroen Borgers asked on Twitter for a standard way to set the JDBC fetch size in JPA, that is, for Hibernate’s Query.setFetchSize() to be added to the standard APIs. This took me slightly by surprise, because nobody has ever asked for that before, but I asked him to go ahead and open an issue. After some discussion, I think I’m satisfied that his actual needs can be met in a different way, but the discussion did help to draw my attention to something important: the default JDBC fetch size for the Oracle driver is 10.

Now, I would never pretend to be an expert in Oracle performance tuning, and I don’t use Oracle every day. Even so, I felt like this is something that I definitely should have known off the top of my head, after so many years working with JDBC.

Out of curiosity, I ran a poll on Twitter, which was shared by Franck Pachot among others:

I think it’s fair to say that Jakarta Persistence has too many options for mapping collections and to-many associations. Way back when we wrote JPA 1.0, I argued against adding so many things, on the grounds that a lot of these options tend to lead users down the wrong path. But the things I wasn’t keen on were ultimately added in JPA 2.0, and I can’t really say this was a bad decision, since all these options are things users ask for.

That said, I’m going to begin by reiterating what I’ve said many times before:

Today someone asked us to add some documentation explaining how to deal with addition of elements to very large collections. I’m not sure if this is a topic I really want to talk about in the documentation, but it’s definitely worth a blog.

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:

Since the JSR-220 Expert Group introduced annotation-based dependency injection and the Java Persistence API as part of Java EE 1.5, it’s been possible to inject an EntityManager or EntityManagerFactory into most Java EE components using the dedicated @PersistenceContext and @PersistenceUnit annotations respectively.

Later, my JSR-299 Expert Group introduced a completely new approach to dependency injection, which ultimately came to be named Contexts and Dependency Injection for Java. Initially very controversial, CDI has over time become central to the Java EE platform—​oops, I mean, Jakarta EE—​and other technologies have adopted CDI, now in its sixth revision, as the base-level component model.

But back in CDI 1.0, I needed a way to bridge the gap between @PersistenceContext and the @Inject annotation supported by CDI. And with CDI itself mired in FUD, I wasn’t exactly in a very strong political position to go asking the EE platform group to redefine their, at the time, pretty much brand-new dependency injection annotations in terms of the crazy new direction we were taking with CDI.