What's the difference between JPA and Hibernat

Question

I understand that JPA 2 is a specification and Hibernate is a tool for ORM. Also, I understand that Hibernate has more features than JPA 2. But from a practical point of view, what really is the difference?

I have experience using iBatis and now I'm trying to learn either Hibernate or JPA2. I picked up Pro JPA2 book and it keeps referring to "JPA provider". For example:

If you think a feature should be standardized, you should speak up and request it from your JPA provider

This confuses me so I have a few questions:

• Using JPA2 alone can I fetch data from DB by simply annotating my POJO's
• Is JPA2 supposed to be used with a "JPA Provider" e.g TopLink or Hibernate? If so, then what's the benefit of using JPA2 + Hibernate as compared to JPA2 alone, or compared to Hibernate alone ?
• Can you recommend a good practical JPA2 book. "Pro JPA2" seems more like a bible and reference on JPA2 (It doesn't get into Queries until the later half of the book). Is there a book that takes a problem/solution approach to JPA2?

Answer 1

Some things are too hard to understand without a historical perspective of the language and understanding of the JCP.

Often there are third parties that develop packages that perform a function or fill a gap that are not part of the official JDK. For various reasons that function may become part of the Java JDK through the JCP (Java Community Process)

Hibernate (in 2003) provided a way to abstract SQL and allow developers to think more in terms of persisting objects (ORM). You notify hibernate about your Entity objects and it automatically generates the strategy to persist them. Hibernate provided an implementation to do this and the API to drive the implementation either through XML config or annotations.

The fundamental issue now is that your code becomes tightly coupled with a specific vendor(Hibernate) for what a lot of people thought should be more generic. Hence the need for a generic persistence API.

Meanwhile, the JCP with a lot of input from Hibernate and other ORM tool vendors was developing JSR 220 (Java Specification Request) which resulted in JPA 1.0 (2006) and eventually JSR 317 which is JPA 2.0 (2009). These are specifications of a generic Java Persistence API. The API is provided in the JDK as a set of interfaces so that your classes can depend on the javax.persistence and not worry about the particular vendor that is doing the work of persisting your objects. This is only the API and not the implementation. Hibernate now becomes one of the many vendors that implement the JPA 2.0 specification. You can code toward JPA and pick whatever compliant ORM vendor suits your needs.

There are cases where Hibernate may give you features that are not codified in JPA. In this case, you can choose to insert a Hibernate specific annotation directly in your class since JPA does not provide the interface to do that thing.

Source: http://www.reddit.com/r/java/comments/16ovek/understanding_when_to_use_jpa_vs_hibernate/

Answer 2

JPA : is just like an interface and have no concrete implementation of it to use functions which are there in JPA.

Hibernate : is just a JPA Provider which have the implementation of the functions in JPA and can have some extra functions which might not be there in JPA.

TIP : you can use

     *combo 1* : JPA + JPA Provider(Hibernate) 
     *combo 2* : only Hiberante which does not need any interface 

Combo 1 : is used when you feel that your hibernate is not giving better performance and want to change JPA Provider that time you don't have to write your JPA once again. You can write another JPA Provider ... and can change as many times you can.

Combo 2 : is used very less as when you are not going change your JPA Provider at any cost.

Visit http://blog-tothought.rhcloud.com//post/2, where your complete confusion will get clear.

Answer 3

JPA is just a specification while Hibernate is one of the JPA provider i.e hibernate is implementing various things mentioned in JPA contract.

Answer 4

From the Wiki.

Motivation for creating the Java Persistence API

Many enterprise Java developers use lightweight persistent objects provided by open-source frameworks or Data Access Objects instead of entity beans: entity beans and enterprise beans had a reputation of being too heavyweight and complicated, and one could only use them in Java EE application servers. Many of the features of the third-party persistence frameworks were incorporated into the Java Persistence API, and as of 2006 projects like Hibernate (version 3.2) and Open-Source Version TopLink Essentials have become implementations of the Java Persistence API.

As told in the JCP page the Eclipse link is the Reference Implementation for JPA. Have look at this answer for bit more on this.

JPA itself has features that will make up for a standard ORM framework. Since JPA is a part of Java EE spec, you can use JPA alone in a project and it should work with any Java EE compatible Servers. Yes, these servers will have the implementations for the JPA spec.

Hibernate is the most popular ORM framework, once the JPA got introduced hibernate conforms to the JPA specifications. Apart from the basic set of specification that it should follow hibernate provides whole lot of additional stuff.

Answer 5

While JPA is the specification, Hibernate is the implementation provider that follows the rules dictated in the specification.

Answer 6

Java - its independence is not only from the operating system, but also from the vendor.

Therefore, you should be able to deploy your application on different application servers. JPA is implemented in any Java EE- compliant application server and it allows to swap application servers, but then the implementation is also changing. A Hibernate application may be easier to deploy on a different application server.