Red Hat

In Relation To JPA

In Relation To JPA

Hibernate ORM 4.3.1.Final Release

Posted by Steve Ebersole    |       |    Tagged as Hibernate ORM JPA Releases

I have just released 4.3.1.Final, the first bugfix release for Hibernate ORM 4.3. In addition to bug fixes, a few improvements of note include:

  • HHH-5289 : Improved performance of reflection calls
  • HHH-6911 : Allows reading and writing @DiscriminatorValue from/to @DiscriminatorColumn when combined with InheritanceType.JOINED (for portability with providers which need DiscriminatorColumn)
  • HHH-8865 : Added a new guide on logging to the growing set of topical guides. This is the first know documentation of any sort on using/configuring JBoss Logging, and also discusses some of the more good-to-know specific logging categories. See

See the release page for details of all changes.

Artifacts can be found in the usual places.

Hibernate ORM 4.3.0.Final Release

Posted by Steve Ebersole    |       |    Tagged as Hibernate ORM JPA Releases

The Hibernate team is proud to announce the Hibernate ORM 4.3.0.Final Release. With this release, Hibernate is now a certified implementation of the JPA 2.1 specification. Certified awesomeness!

A lot of work has gone into this release over the last few months. The main focus of 4.3 was JPA 2.1 support, so much of the work these past few months focused on new JPA 2.1 features. The new features defined for JPA 2.1 include:

  • Support for stored procedures. See my previous blog for details
  • CriteriaUpdate and CriteriaDelete allow definition and execution of UPDATE and DELETE queries in type-safe Criteria form.
  • Entity listeners can now take advantage of dependency injection through CDI.
  • AttributeConverters, which define the ability to apply conversions on basic values between their database representation and their representation in your domain model. This is similar in concept to Hibernate's Type contract, although certainly less powerful (can only apply to basic values and operate on in-memory values). On the positive side, JPA AttributeConverters are portable across providers.
  • Entity Graph support
  • Standardized schema generation. With 2.1 JPA now defines schema generation which is standardized across providers in terms of how generation is performed and the settings providers understand as a baseline. Arun Gupta has a good write up of the basic schema generation support.
  • Synchronization of persistence contexts via SynchronizationType
  • @ConstructorResult support in result set mappings for native queries

The significant non-JPA work that has gone into 4.3 includes:

  • Continued improvement in Hibernate's support for OSGi environments. OSGi support in 4.3 is still somewhat bound by certain design limitations within Hibernate, We plan to fully address these limitations in 5.0 (see HHH-8501 for details).
  • Continued work on new bytecode enhancement support within Hibernate, adding support for inline dirty checking. See HHH-8354 for details.
  • Initial break down of the monolithic DocBook-based manuals into smaller Asciidoc-based topical guides (HHH-8606). This is an ongoing process.

Hibernate ORM 4.3.0.CR2 Release

Posted by Steve Ebersole    |       |    Tagged as Hibernate ORM JPA Releases

The second release candidate for Hibernate ORM 4.3.0 is just released. There were a few issues with CR1 that required a second CR, especially HHH-8739 and HHH-8759.

The full change log for the release can be seen at

In 2 weeks we'll decide whether a CR3 is needed or release Final at that time.

Thanks for all the feedback!

Hibernate ORM 4.3.0.CR1 Release

Posted by Steve Ebersole    |       |    Tagged as Hibernate ORM JPA Releases

The Hibernate team is proud to announce the 4.3.0.CR1 release of Hibernate ORM. This is the first release candidate for 4.3 and JPA 2.1 support. For those who maybe are not familiar with our release methodology, this means that in 2-3 weeks this release will essentially be re-tagged as Final unless some critical bugs are reported with it in the meantime.

I will do a full break down of all the new goodies added over the course of 4.3 development in the Final release announcement. Specific development of note done for CR1 include:

  • Support for JPA 2.1 EntityGraphs. This was the biggie holding us back from going to CR. HHH-8285 and friends
  • Integration of the Hibernate JPA Static Metamodel Generator into the ORM project - HHH-8483
  • Starting on break down of the monolithic DocBook-based manuals into smaller Asciidoc-based topical guides (ongoing) - HHH-8606
  • A number of performance fixes including HHH-8709, 8704, 8698, HHH-8682, etal.

The full version info (including change log) can be seen on the version page

Artifacts and release bundles can be found in the normal places.

Hibernate ORM 4.3.0.Beta5 Release

Posted by Steve Ebersole    |       |    Tagged as Hibernate ORM JPA Releases

Version 4.3.0.Beta5 release of the Hibernate ORM project has just been released. This is a step closer towards JPA 2.1 compliance, but also lots of other goodies. JPA 2.1 work of note includes:

  • HHH-8478 - which should complete AttributeConverter support.
  • HHH-8445 - which adds support for REF_CURSOR parameters and should complete StoredProcedureQuery support.
  • HHH-8276 - which was the major prerequisite step for entity graph support. You'll be using that anytime you load entities directly or by to-one association.
  • HHH-8523 - which improves support for parameters and returns using an explicit TemporalType and defined as Calendar

Entity graph support is still not complete, but as mentioned above most of the necessary prerequisite work has been covered now under HHH-8276 and HHH-7841.

Non JPA 2.1 work of note includes:

  • HHH-8476 - which now manages associated many-to-many table rows with bulk deletes (HQL/JPQL)
  • HHH-7689 - which implements better clean up of JDBC batches during failed transactions. The previous behavior led to problems in the way Spring attempts to reuse Sessions after exceptions (which is technically not supported, but this was a good change to make anyway)
  • HHH-8354 - which adds on top of the new bytecode enhancement work to weave in in line dirty checking. In other word, we now have the ability to have entities and embeddables track their own state changes (via enhancement) and for Hibernate to leverage that knowledge during flush. This is still very young, but promises to significantly reduce flush times in many use-cases. We'll have more announcements about all the bytecode enhancement enhancements later.
  • HHH-8520 - ability to use the hibernate.globally_quoted_identifiers with HBM mappings

The full changelog can be found in Jira at Artifacts can be found in the usual places.

Beta6 is scheduled in Jira already following the normal 4 week time box, however be aware that that release is likely to not happen on that particular day; its more likely to be the week before or the week after as I am traveling that particular week. I'll keep Jira up to date as we go along.

Thanks for the support and contributions!

Hibernate ORM 4.3.0.Beta4 release

Posted by Steve Ebersole    |       |    Tagged as Hibernate ORM JPA Releases

Back to work after summer fun :)

This release has a lot of work, quite a bit in the form of pull requests. Thanks again!

A lot of the focus here has been on JPA 2.1 support. At this point:

  • AttributeConverter support should be complete; just about- there is still one minor issue which will be addressed in the next release
  • StoredProcedureQuery support should be complete; just about - there is still an issue here too which will be addressed in the next release
  • @ConstructorResult support is mostly done, though you currently can only use one ConstructorResult result per query which will be followed up by
  • JPA schema generation support should be fully done at this point.
  • EntityGraph support is still not in place, though support for loading entities using LoadPlans (which is the internal fulfillment of entity graphs) is done and support for collections is under way.
  • Applications using JPA native (native SQL) query support should be aware of a potentially significant change to better align with the JPA spec. Essentially Hibernate will now flush the EntityManager before running the native query (as long as we are within a transaction). Note that this is a full flush, unlike HQL/JPQL or Criteria queries which perform a partial flush. In Hibernate native SQL query support, partial flush is achievable which is available to JPA native queries by unwrapping. For details see

Non-JPA-related changes to highlight include:

The full changelog can be found in Jira at Artifacts can be found in the usual places.

Also, along with this release came a new release (4.0.4.Final) of the hibernate-commons-annotations support library. For the 2 of you out there who care ;)

Anyway, we will now be back at a 4-week timebox. So the next release (Beta5, or CR if we get to that point by then) will be in 4 weeks from now.


Hibernate ORM 4.3.0.Beta3 Release

Posted by Steve Ebersole    |       |    Tagged as Hibernate ORM JPA Releases

The Hibernate team is pleased to announce today's release of Hibernate 4.3.0.Beta3. Support for entity graphs is still a work in progress, but all other JPA 2.1 features should be fully operational. Specific JPA 2.1 features fully functional as of this release include:

For the full break down of changes, see the changelog.

Hibernate ORM 4.3.0.Beta2 Released

Posted by Brett Meyer    |       |    Tagged as Hibernate ORM JPA Releases

Hibernate ORM 4.3.0.Beta2 was just released. The full changelog can be viewed here

This release includes several notable changes. Some of this will borrow from the 4.2.1 announcement:

  • ORM is now enforcing checkstyle within all modules. This was applied in HHH-8156. Violations were corrected in HHH-8159 and will continue to be corrected under HHH-8211 for 4.3.0.Beta3.
  • HHH-8175 Official support for Postgresql 9.2, Postgres Plus 9.2, and IBM DB2 10.1. Luckily, these mostly worked out-of-the-box with our existing dialects. Only a few test changes were necessary.
  • HHH-7797 (release 4.2.0 and 4.3.0.Beta1) changed the way uniqueness is handled. Rather than mixing "unique" on column definitions, "unique(columns...)" on table definitions, unique indexes, and unique constraints, all were changed to solely use unique constraints (DB2 is the exception -- indexes are use in certain circumstances). Follow-up issues were corrected in this release: HHH-8162 and HHH-8178.
  • More details about HHH-8162: Since unique constraints are now the default, special handling was necessary within SchemaUpdate. The method used is configurable, selected with the "hibernate.schema_update.unique_constraint_strategy" property. DROP_RECREATE_QUIETLY is the default. It attempts to drop, then (re-)create each unique constraint within your model. All errors and exceptions (constraint doesn't exist, constraint already existed, etc.) are ignored. RECREATE_QUIETLY is the same, but does not attempt the drop. SKIP will not attempt to drop or create unique constraints at all on the SchemaUpdate.
  • HHH-7617 Support for generating Eclipse IDE projects was improved. Please see this post for more info.
  • HHH-7944 Envers is now supported in OSGi.
  • HHH-7943 improved the c3p0, proxool, ehcache, and infinispan strategies. All are now selectable in configurations by both classname and a short name. Further, their strategies were integrated as OSGi services. Note that HHH-7943 has multiple follow-on tickets due to classloader issues found with many of the 3rd party bundles.
  • HHH-7993 supports basic OSGi Bundle scanning to automatically discover entities and mappings in your persistence unit bundle.
  • HHH-8183 supports synonyms in schema validation. Enable the capability with the "hibernate.synonyms=true" property (disabled by default).
  • HHH-8203 ensures support of Proxool 0.9.1.
  • Deprecations: Hibernate's @ForeignKey in HHH-8170 (use JPA's @ForeignKey), @IndexColumn and @ListIndexBase in HHH-8163, and @Sort in HHH-8164 (use @SortNatural or @SortComparator)

JBoss Nexus:
Maven Central: (should update in a couple of days)
Downloads: 4.3.0.Beta2 ZIP, 4.3.0.Beta2 TGZ

Hibernate ORM 4.3.0.Beta1 Release

Posted by Steve Ebersole    |       |    Tagged as Hibernate ORM JPA Releases

The Hibernate team is pleased to announce today's release of Hibernate 4.3.0.Beta1 which targets the (still not finalized) JPA 2.1 specification which is part of the upcoming Java EE 7 platform. This is the first release targeting JPA 2.1 support. As mentioned, JPA 2.1 is not completely finalized so this support should be considered a preview. JPA 2.1 defines a number of enhancements. I won't go in depth in each of them here as I plan to follow up with separate in-depth blog posts for some of these features. However, the web abounds with good summaries of the new features; for example:

One feature that I did not see discussed much is the notion of entity graphs. This Beta1 release has very limited support for entity graphs. You can define entity graphs, but at the moment they are not taken into account while loading data. This will be the focus of Beta2.

4.3 continues building on the OSGi support begun with 4.2, and also contains many other improvements and fixes. For the full break down of changes, see the changelog.

As usual, the artifacts have been uploaded to the JBoss Nexus repository (which is synchronized to Maven Central regularly) and the release bundles have been uploaded to the Hibernate SourceForge in both ZIP and TGZ formats.

Callable statement support

Posted by Steve Ebersole    |       |    Tagged as Hibernate ORM JPA

The soon-to-be final JPA 2.1 specification adds standardized support for dealing with JDBC CallableStatements (stored procedure and function calls). Arun Gupta has a decent summary of the initial JPA 2.1 features, including Stored procedure support, at Standardized here means both across providers as well as across database vendors. Pretty sweet. As much as I liked the idea of standarized support for handling callable statements, I was not overly thrilled with certain aspects of the proposed JPA StoredProcedureQuery API. My worries were mainly around how the outputs were accessed, especially when multiple results are expected. Let's first look at a simple example of a procedure returning a result:

StoredProcedreQuery query = entityManager.createStoredProcedureQuery( "top10SalesmenByQuarter", Employee.class );
query.registerStoredProcedureParameter( "quarter", String.class, ParameterMode.IN );
query.setParameter( "quarter", "Q1-2000" );
List top10Salesmen = query.getResultList();

Nothing too odious there.

However, imagine that we instead want to call a procedure that has a mix of update counts and results. This is where, in my humble opinion, the StoredProcedureQuery gets a bit dodgy. Largely it tries to follow the JDBC paradigm for accessing mixed returns. The argument for that approach of course is that it is familiar to developers familiar with the JDBC API. Lets take an example:

StoredProcedreQuery query = entityManager.createStoredProcedureQuery( "mixedReturns" );
while( 1==1 ) {
    boolean isResult = query.hasMoreResults();
    if ( isResult ) {
        handleResult( query.getResultList() );
    else {
        int updateCount = query.getUpdateCount();

        // complete exit condition is ( ! query.hasMoreResults() && query.getUpdateCount != -1 )
        if ( updateCount == -1 ) {

        handleUpdateCount( updateCount );

To me, thats not very user friendly. However I was not able to get proposed changes to that API in. So I instead decided to develop an alternate API; A Hibernate-native API accessed through Session. The above query, using that API would look like:

org.hibernate.procedure.ProcedureCall call = entityManager.unwrap( Session.class ).createStoredProcedureCall( "mixedReturns" );
org.hibernate.procedure.ProcedureResult callResult = call.getResult();

while ( callResult.hasMoreReturns() ) {
    final org.hibernate.result.Return return = callResult.getNextReturn();
    if ( org.hibernate.result.ResultSetReturn.class.isInstance( return ) ) {
        handleResult( ( (org.hibernate.result.ResultSetReturn) return ).getResultList() );
    else {
        handleUpdateCount( (org.hibernate.result.UpdateCountReturn) return ).getUpdateCount() );

Both APIs support processing of multiple ResultSets too. If return classes or result-set-mappings are supplied, they apply to all of the processed ResultSets:

StoredProcedreQuery query = entityManager.createStoredProcedureQuery( "top_and_bottom_salesmen_by_quarter", Employee.class );
query.registerStoredProcedureParameter( "quarter", String.class, ParameterMode.IN );
query.registerStoredProcedureParameter( "top_salesmen", String.class, ParameterMode.REF_CURSOR );
query.registerStoredProcedureParameter( "bottom_salesmen", String.class, ParameterMode.REF_CURSOR );
query.setParameter( "quarter", "Q1-2000" );

// we will end up with 2 result lists, where each list contains elements of type Employee.  Pretty sweet!

boolean isResult = query.hasMoreResults();
while( isResult ) {
    handleResult( query.getResultList() );
ProcedureCall call = entityManager.unwrap( Session.class ).createStoredProcedureCall( "top_and_bottom_salesmen_by_quarter", Employee.class );
call.registerParameter( "quarter", String.class, ParameterMode.IN );
call.registerParameter( "top_salesmen", String.class, ParameterMode.REF_CURSOR );
call.registerParameter( "bottom_salesmen", String.class, ParameterMode.REF_CURSOR );
call.setParameter( "quarter", "Q1-2000" );

// we will end up with 2 result lists, where each list contains elements of type Employee.  Pretty sweet!

ProcedureResult callResult = call.getResult();
while ( callResult.hasMoreReturns() ) {
    final ResultSetReturn rtn = (ResultSetReturn) callResult.getNextReturn();
    handleResult( rtn.getResultList() );
back to top