In Relation To

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.

I had so many interesting new things to talk about in the summary of Jakarta Persistence 3.2 that I forgot to mention an important thing we’re taking away.

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.

Today we’re excited to announce that Hibernate is moving to the Commonhaus Foundation. For the last 20 years, development of Hibernate has been funded and sponsored by JBoss, and then by Red Hat. This support will continue just as before, since Hibernate remains a critical component of JBoss EAP, WildFly, and Quarkus, but the project itself will now be hosted on neutral ground.

Cross-posted from Substack.

One of the most important experiences of my career was working with Linda DeMichiel from Sun, Mike Keith from TopLink, Evan Ireland from Sybase, and others, to design and write the first version of the Java Persistence specification.

Today this technology enjoys broad acceptance, even among former critics. But in recent years, despite a name change to Jakarta Persistence, the spec has not evolved rapidly. Not until now, that is. Over the last year or so, Lukas Jungmann from Oracle and I have been working rather hard to bring you the biggest release of Persistence in a long time.

This post will concentrate on new features we’ve added to Jakarta Persistence. It’s worth mentioning that quite a lot of work has gone into clarifying the semantics of existing features, and rewriting certain sections of the spec for clarity and readability. This is an ongoing effort. The spec is more than 500 pages in length; rewriting such text without accidentally changing its meaning is a slow and painstaking process.

In a previous post I talked about Jakarta Data. Alignment of the two specifications has been a further priority.