Menu
Conclusion: The major difference between Hibernate and JPA is that Hibernate is a framework while JPA is API specifications. Hibernate is the implementation of all the JPA guidelines.
JPA is a standard, while Hibernate is not. In hibernate, we use Session for handling the persistence of data, while in JPA, we use Entity Manager. The query language in Hibernate is Hibernate Query language, while in JPA, the query language is Java Persistence query language. Hibernate is one of the most JPA providers.
JPA can be used without a JPA provider aka Hibernate, EclipseLink and so on only if the application server has already a JPA implementation.
JPA uses EntityManager interface to create/read/delete operation and maintains the persistence context. Hibernate uses Session interface to create/read/delete operation and maintains the persistence context. JPA uses JPQL (Java Persistence Query Language) as Object Oriented Query language for database operations.
As you state JPA is just a specification, meaning there is no implementation. You can annotate your classes as much as you would like with JPA annotations, however without an implementation nothing will happen. Think of JPA as the guidelines that must be followed or an interface, while Hibernate's JPA implementation is code that meets the API as defined by the JPA specification and provides the under the hood functionality.
When you use Hibernate with JPA you are actually using the Hibernate JPA implementation. The benefit of this is that you can swap out Hibernate's implementation of JPA for another implementation of the JPA specification. When you use straight Hibernate you are locking into the implementation because other ORMs may use different methods/configurations and annotations, therefore you cannot just switch over to another ORM.
For a more detailed description read my blog entry.
JPA is the dance, Hibernate is the dancer.
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/
JPA is the interface while Hibernate is the implementation.
Traditionally there have been multiple Java ORM solutions:
each implementation defining its own mapping definition or client API. The JPA expert group gathered the best of all these tools and so they created the Java Persistence API standard.
A standard persistence API is very convenient from a client point of view, making it relatively easy to switch one implementation with the other (although in practice it's not that simple because on large projects you'll have to use specific non-standard features anyway).
The standard JPA has pushed Java ORM competition to a new level and this can only lead to better implementations.
As explained in my book, High-Performance Java Persistence, Hibernate offers features that are not yet supported by JPA:
@SQLInsert, @SQLUpdate, @SQLDelete) statements@FilterDef, @Filter, @Where) and entity filters (e.g. @Where)@Formula)@Immutable)FlushMode.MANUAL, FlushMode.ALWAYS)Cache(usage = CacheConcurrencyStrategy.READ_WRITE))@OptimisticLock(excluded = true))OptimisticLockType.ALL, OptimisticLockType.DIRTY)@Where, @Filter)These extra features allow Hibernate to address many persistence requirements demanded by large enterprise applications.
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.
JPA is just a specification which needs concrete implementation. The default implementation oracle provide is "Eclipselink" now. (Toplink is donated by Oracle to Eclipse foundation to merge with eclipselink)
(Reference : http://www.oracle.com/technetwork/middleware/toplink/index-085257.html http://www.eclipse.org/org/press-release/20080317_Eclipselink.php )
Using Eclipselink, one can be sure that the code is portable to any implementation if need arises. Hibernate is also a full JPA implementation + MORE ( Sort of JPA Plus). Hibernate is super set of JPA with some extra Hibernate specific functionality. So app developed in Hibernate may not be compatible when switched to other implementation. Still hibernate is choice of majority of developers as JPA implementation and widely used.
Another JPA implementation is OpenJPA (openjpa.apache.org) which is an extension of Kodo implementation.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With