Frank Sommers: In the beginning there was Hibernate Core, and now, in addition to the Core, we have Hibernate Annotations, Hibernate EntityManager, and Hibernate Tools. Could you give us a brief overview of what these tools do and how they relate? What's new in these tools for 3.2?

Steve Ebersole: Just as before, Hibernate Core provides the main object/relational mapping behavior and APIs that are familiar to most as "Hibernate." The other packages build on top of the functionality provided by the core.

Hibernate Annotations provides the capability to define the metadata Hibernate needs to perform its functionality via JDK 5 annotations, as an alternative to the XML metadata approach. Starting with 3.2, Hibernate Annotations now provide all the capabilities available in the XML approach. Plus, they offer additional functionality not available in the XML metadata such as the Lucene and Validator integrations.

Hibernate EntityManager, along with portions of Hibernate Annotations, provide Hibernate's implementation of the Java Persistence API. The 3.2.0.ga release is the one we used to certify Hibernate as an implementation of the Java Persistence API.

Frank Sommers: Apart from the JPA being a Java standard, what are the main differences from a developer's perspective between using Hibernate directly versus using it as a JPA persistence provider?

Steve Ebersole: From a developer's perspective, we would need to talk about API sets. In terms of basic API operations, there is very little difference at all.

For example, both EntityManager and a Hibernate Session offer methods named merge() which define the same exact behavior, etc. The main API difference is access to advanced functionality provided by Hibernate that is not defined by the JPA.

For example, Hibernate defines methods to allow the developer to manage the size of the persistence context. This is very important functionality, especially when we talk about extended persistence contexts which might exist for a long time and continue to grow in size.

Plus, in general, JPA defines one semantic for each type of operation. If I have an entity representing detached state, I need to utilize merge() or lock() in terms of reattaching that state in JPA. Hibernate, however, offers merge(), lock(), update(), saveOrUpdate(), saveOrUpdateCopy(), or replicate(), all of which operate on detached state with slightly different semantics.

Frank Sommers: In addition to differences in managing the semantics of detached objects, are there other Hibernate features not currently supported in the JPA? And are there JPA features not currently supported in Hibernate?

Steve Ebersole: Hibernate completely implements the JPA spec, including all optional behaviors. In terms of Hibernate features not covered by JPA... well, quite a few actually. Query-by-Criteria/Query-by-Example is probably the biggest omission.

As I mentioned before, the ability to control the size of the state managed within a persistence context is another feature provided by Hibernate but which is not defined by the specification; also it completely misses out on defining any kind of shared state caching semantics.

As well, Hibernate has a very powerful and flexible type system, whereas JPA defines only a minimal set of database to object type conversions.

Frank Sommers: Annotations are a convenient feature to specify persistence-related features. Are there circumstances when you would still recommend that developers use XML mapping files?

Steve Ebersole: First, I'd like to point out that it is really not an either/or type decision. Users can mix and match the use of annotations and XML mapping. However, there are two situations where users would need to use XML.

The first one would be where a user is taking advantage of "entity names"; this is a feature where you can simultaneously map a given POJO class to multiple entity names. This is not possible with annotations, and so you would need to map at least one of the entities using XML.

The second circumstance would be where a user is utilizing the "entity mode" feature of Hibernate. This is also not available in annotations, as it assumes you are working with POJOs.

Hibernate's entity mode is the idea of being able to represent your domain model in different ways in memory. For example, Hibernate supports a DOM4J entity mode. When you use the DOM4J entity mode and ask Hibernate to get something out of the database for you, what you get back is an org.dom4j.Element. POJO is just another entity mode to Hibernate.

Outside of entity names and entity modes, it is really just a matter of taste.

Frank Sommers: Speaking of annotations, what are the differences between Hibernate annotations and the persistence-related annotations specified in the JPA specs?

Steve Ebersole: The difference is breadth. JPA defines the common subset of object/relational mapping constructs via its annotations. Essentially, it defines the minimum mapping constructs one would need to implement object persistence.

However, Hibernate has by far the richest mapping constructs in this space. As of the 3.2 release, Hibernate Annotations fully supports both the JPA mapping subset as well as the full range of the Hibernate mapping constructs.

As a result, Hibernate Annotations mirrors powerful Hibernate features such as batch fetching, subselect fetching, union subclass mapping, type mapping, cache semantic mapping, etc., which JPA does not include. Plus, as I have mentioned already, Hibernate Annotations also encompasses powerful behavior beyond what is available in the Hibernate Core.

Frank Sommers: Could you tell us a bit about integration with Lucene?

Steve Ebersole: This work is being led by Emmanuel Bernard. It builds on Hibernate Annotations and the event framework of Hibernate Core. The idea is to delegate maintenance of Lucene indexes that are populated based on domain entity state to Hibernate based on persistence events.

Whenever you update or delete or insert a new entity instance, Hibernate fires events in response to these actions which the Lucene integration listeners pick up on and perform any needed actions on the Lucene indexes. The beauty of the whole integration is the simplicity of the solution: you get all this from just a few annotations on your domain classes and a few extra lines of Hibernate configuration for the listener stack.

Frank Sommers: What are some of the interesting features you're planning for the next Hibernate release?

Steve Ebersole: I am currently working on a slew of new HQL features, such as ad-hoc join syntax and UNION/MINUS queries; this is all being done on top of the Antlr-based query translator we introduced in 3.0.

I am also in the midst of re-working how Hibernate itself speaks to JDBC. Depending upon how that turns out, we may or may not decide to expose that work for user consumption as an alternative means of accessing JDBC alongside a Hibernate Session.

I'll continue to expand on the "entity mode" capabilities both in terms of making it easier to use as well as adding new standard modes. I also need to catch Criteria queries up fully to HQL in terms of capabilities and feature set.

Hibernate Lucene and Hibernate Validator represent other areas where we will continue to grow feature sets.