The first Beta of Hibernate ORM 6.0 has just been released.
We had a few main focuses for this Beta:
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
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:
@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
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
TimeZoneStorageType defines the following strategies:
(default) Hibernate’s legacy behavior of normalizing to UTC prior to writing
Rely on the underlying database’s
WITH TIMEZONEsupport. Throws an exception if the database does not natively support
WITH TIMEZONEas intended by the SQL spec. This last part is important as it precludes databases (PostgreSQL, e.g.) which define a
WITH TIMEZONEbut do not actually store the timezone.
Use a separate column to store the timezone. This splits the value into 2 columns which we anticipate having various limitations. Note that this strategy is not yet implemented.
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:
Custom composite types (see above)
Custom collection types (see above)
Cache providers - starting in 5.x, Hibernate moved to only support pluggable cache implementations through the JCache specification. The
hibernate-jcachemodule uses Ehcache (as a JCache implementation) for testing. Unfortunately, Ehcache defines a dependency on Java EE which conflicts with Hibernate’s migration to Jakarta EE. Since we cannot test the module, we did not feel comfortable releasing it as part of this Beta. We will monitor the situation and hopefully re-enable this module soon.
Statistics - not all statistics have been re-wired yet.
Gradle plugin. Gradle’s plugin publishing plugin has been giving us problems trying to release this Beta. So in the interest of getting Beta1 published, we will temporarily disable publishing this plugin until that can get sorted out
We know these are not working, so no need to create Jira issues for these.