Use of Hibernate 3.0 with EJB 3.0 & JPA

Question

Where I'm working the guys that are sitting across from me are working on a project. This is a JavaEE app which uses Struts, Spring, EJB 3.0, JPA, and Hibernate 3.0. They are using EJB 3.0 entity beans with annotations. I've been asking them why Hibernate 3.0 is in this mix and noone can seem to tell me. It feels like they've included Hibernate 3.0 because they were told to but are not using it for anything that they can't get from EJB 3.0 entity beans/JPA. They're using CMP and accessing all of the database functions via EJBs.

Can Hibernate give you anything in this setup that can't be provided by EJB 3.0/JPA?

Answer 1

Hibernate does have a JPA implementation but it can also be used standalone. It is possible to use Hibernate as the persistence provider in JavaEE. The JBoss application server for example uses Hibernate for its persistence. So if you are using Hibernate to provide the persistence in the app server, it may make sense.

If you are using an app server that does not use Hibernate for the persistence, then it sounds like you might not need it. Hibernate does have some extensions and things that are not available in JPA. Many other persistence providers also have these extensions (like Toplink or Eclipselink). Check with your app server provide to see if they have the extensions you might need or something similar to what you might have used in Hibernate.

Answer 2

JPA itself is just a specification, not a product, it cannot perform persistence or anything else by itself. JPA is just a set of interfaces and requires an implementation (a persistence provider). There are open source and commercial JPA implementations (Toplink Essentials, EclipseLink, Hibernate EntityManager, OpenJPA, Kodo, etc) and any Java EE 5 (or Java EE 6) application server must provide support for its use (JBoss uses Hibernate EntityManager, GlassFish v2 uses Toplink Essentials by default, GlassFish v3 uses EclipseLink by default, WebLogic uses Kodo by default, etc)¹.

Now, one of the nice things with JPA is that it can be used outside a container, for example in a Java SE application or in a testing context (that was one of the big problems with EJB 2.x). But in that case, you need to provide an implementation as you won't get the one provided by the container. As we saw, Hibernate EntityManager - which is build on top of Hibernate Core - is one of them and this may explain why you see it.

_{¹ Note that most (all?) containers offer a way to replace the default implementation that they provide. It is for example possible to use Hibernate instead of Kodo with Weblogic or instead of EclipseLink with GlassFish. This may be another reason why you see it in the mix.}