In Relation To

Jakarta Persistence is replacing Java Persistence as Java EE transitions to Jakarta EE. See this blog for details.

For users, this means transitioning from the javax.persistence namespace to jakarta.persistence. This affects both package/class names as well as setting/hint names. There are tools which help with this migration.

For the short-term at least, Hibernate strives to support both sets of setting and hint names.

The type system in 6.0 has been evolving to account for the new read-by-position approach to reading JDBC results. Since these contracts are changing anyway and because this is a major release, we took the opportunity to improve the type system and part of that has implication for users. The main change here is the removal of the ability to write custom types using the BasicType contract. All custom types are now based on the UserType contract.

In a future 6.0 Beta, we will also be dropping the various BasicType implementations. Applications relying on those specific classes should begin migrating to the alternatives.

In this Beta, only custom basic types are supported.

The new custom composite type contracts are still being discussed.

The new custom collection type contract will be based on the CollectionSemantics contract, though the best way to expose that is still in discussion

The plan is to add support for both custom composite types and custom collection types in the next Beta.

There are new annotations for applying these new contracts. In general, all String-based type specification through annotations have been removed. This was a poor original choice when Hibernate first added annotation support - it simply exposed XML as annotations. The specific alterations include removal of:

Additionally, @ParamDef#type will be replaced for the next Beta.

The new annotations are very well covered in the User Guide. See specifically the Basic Type and @Any mapping sections of the Domain Model chapter.

One important thing of note is the ability to use these new annotations as meta-annotations. See the @Any mapping section for a nice example as a replacement for @AnyMetaDef

Previous versions of Hibernate used a "normalization" scheme for storing timezone information; timezone-based values were normalized to UTC before writing to the database. While this is generally the best strategy, some users might prefer using another strategy such as using WITH TIMEZONE SQL data-type variants. To this end, Hibernate has added the TimeZoneStorageType enum to specify how to handle timezone details. This strategy can be specified per-SessionFactory using the hibernate.timezone.default_storage setting or per-attribute using the @TimeZoneStorage annotation. TimeZoneStorageType defines the following strategies:

Support for procedure calls, through both Jakarta Persistence and Hibernate native APIs, are implemented.

One outstanding issue, which is actually an improvement, is related to result-set mapping.

It is a Beta, so while we will minimize API changes from this point forward (aside from not-yet implemented features, see below) there may still be some minor changes as we move forward. But generally speaking users can consider the APIs as stable.

There are still a few things we need to implement or fix. This is not a comprehensive list, but a good start on things we know are not working:

We know these are not working, so no need to create Jira issues for these.

See the user guide and migration guide.

Also check out the release page.

To get in touch, use the usual channels as discussed on https://hibernate.org/community/