Hibernate and JPA, what to use, where?

Question

Could someone please explain to me what the main differences are between JPA and Hibernate?

Where to use Hibernate ?

Where to use JPA?

Why not entity bean?

Answer 1

JPA is a specification. Hibernate is one implementation of the spec. Another implementations is Toplink, but there are others.

You should try to rely as much as possible on the standard JPA features. There are however a few Hibernate-specific useful features, but they will make your app less portable if you decide to switch the implementation.

By entity bean, you mean EJB 2.x entity bean? This is a "dead" technology which proved to be too hard to use.

Answer 2

A little history:

Entity beans were part of EJB 1 and 2. They were hell to work with, so an alternative was due. Then Hibernate appeared. (I don't remember these times)

Hibernate evolved to be a de-facto standard in object-relational mapping. Then it was decided that a standard is needed, so the JPA specification was created, highly influenced by Hibernate.

JPA is just a specification - it defines what an ORM framework should do, and what annotations should it support. JPA is implemented by many vendors - Hibernate, EclipseLink, OpenJPA, etc.

So:

• don't use Entity beans
• use any JPA implementation that you like. Hibernate is definitely a good choice.

Update: About your secondary question in the comments:

Yes, you can use JPA with EJB Session beans:

@Stateless
public class YourSessionBean implements RemoteInterface {

     @PersistenceContext
     private EntityManager entityManager; // this is the JPA EntityManager
}

And you have the entity manager injected by the container and ready to operate JPA entities. Of course you'd need to make configurations for that, but that's out of the scope of this question.

Answer 3

Differences are subtle and quite difficult to understand:

1. JPA is Java EE's API for Object-Relational mapping. You should have JPA in every single full Java EE application server on earth.
2. Hibernate is JBoss' implementation of JPA. The reason people often confuse both is because JPA is somewhat inspired on Hibernate.
3. Entity Bean is just a concept. This concept means that you will represent your Java EE's solution persisted entities with Java classes. I.E. if you have a customers in your system, you will probably have a Customer entity bean for each customer on your database. You control (create, update, delete, retrieve) your entity beans with JPA. People sometimes confuse Entity Beans with older implementations of Entity Beans in Java EE 1.4 and previous versions. Truth is, you can still have Entity Beans with JPA/Hibernate (or JPA/Toplink) on newer Java Application Servers.

Answer 4

Here you can find some more insight into the question: JPA & Hibernate presentation

Answer 5

I find that for practical purposes all JPA implementations including hibernate are extremely similar and will work for the same use cases. However they tend to be a bit, euhmmm...., temperamental if they are used for things which they were not designed for.

Since you appear to be deciding on a persistence framework, I'd like to bring to your attention that there are other frameworks which work very well in other use cases where the JPA are difficult to use.

iBatis allows you to write plain SQL queries in a separate file and map them to java objects. This keeps the SQL code out of your Java code. You give the queries a name and refer to that name in your code. This works extremely well with larger legacy database where you need to integrate with.

For some simple informal queries things like the Spring JdbcTemplate work also good without the cognitive load of the previous frameworks.

Answer 6

A list of some of the major vendors of JPA are on http://en.wikipedia.org/wiki/Java_Persistence_API under the JPA2 section.

Best to make your own decisions regarding implementation since it's you who will be supporting your application, but always stick to standards-based features rather than "addons"; you'll benefit in the long run