Hibernate vs JPA: What's the difference between them?

Hibernate and JPA compared

During my recent update to TheServerSide’s JDBC definition, I researched commonly queried terms related to the database API and was surprised by just how many people are still confused about the difference between JPA and Hibernate.

According to my research, the term “What is JDBC?” is queried 2,900 times per month. The term “Hibernate vs. JPA” gets queried 3,600 times. So, there is clearly a great deal of confusion between these two very different, yet related, topics.

I’m taking this opportunity to hopefully clarify, once and for all, the similarities and differences between the Java Persistence API and Hibernate.

The difference between JPA and Hibernate

The main difference between JPA and Hibernate is the fact that JPA is a specification. Hibernate is Red Hat’s implementation of the JPA spec.

There is only one JPA specification. The JPA specification is collaboratively developed through the Java community process (JCP) and updates are released as Java specification requests (JSRs). If the community agrees upon all of the changes proposed within a JSR, a new version of the API is released.

When JPA 2.0, JSR #317, was released in 2009, JCP committee members who voted for the specification’s approval included Oracle, IBM, Red Hat, VMWare and Sun Microsystems. As you can see, a number of big names in the software industry participate in the evolution of the API.

The Java Persistence API’s final ballot approval.

The difference between a specification and an implementation

There is only one JPA specification. But, there are many different implementations.

Various projects, including DataNucleus, TopLink, EclipseLink, OpenJPA and Hibernate, provide an implementation of the JPA specification. These projects, and the vendors behind them, compete by trying to provide implementations that are faster, more efficient, easier to deploy, integrate with more external systems and potentially have less restrictive licenses than the others. Hibernate is simply one of many implementations of the JPA specification, albeit the one with which Java developers tend to be the most familiar.

The JPA or Hibernate question

The fact of the matter is, the JPA vs. Hibernate question isn’t a great one, because there really isn’t any intersectionality between the two concepts. You can’t really pull out a Java profiler like JDK Mission Control and compare JPA and Hibernate in terms of performance, scalability or reliability because the two don’t really compete on those axes. JPA is the spec. Hibernate is an implementation.

No organization needs to choose between Hibernate and JPA. An organization either chooses to use JPA or not. And if an organization does choose to use the Java Persistence API to interact with their relational database systems, they can choose between the various implementations, and one of the most popular ones is the JBoss Hibernate project.

Why all the Hibernate vs. JPA confusion?

Given the fact that JPA and Hibernate fulfill two very distinct and different roles, the question arises as to why there is so much confusion when it comes to these two terms. From what I can tell, the confusion traces back to when the JPA specification was originally released.

Prior to the initial release of JPA 1.0 in 2006, there were a number of vendors competing in the object-relational mapping (ORM) tools space, all of whom have very similar APIs that accomplished many of the same objectives. But, none of those projects had compatible and interchangeable code. The goal of JPA was to standardize how Java applications performed ORM. With JPA 1.0, all of the competing implementations were unified because they all now implemented a common, standard API.

However, because of Hibernate’s popularity, many people continued to use the term Hibernate when they really meant JPA. Hibernate became an eponym for JPA, just as Kleenex is an eponym for bathroom tissues. Even today, when developers and architects talk about Hibernate, they’re really just referring to the JPA spec.

A JavaBean decorated with JPA annotations.

Choosing between JPA and Hibernate

I mentioned earlier that nobody has to choose between JPA and Hibernate, because all of the functionality provided by Hibernate can simply be accessed through the JPA API. However, that hasn’t always been the case. There was actually a time, during the early days of JPA releases, in which the choice between JPA and Hibernate was a legitimate decision organizations had to make.

The initial JPA release was very basic, and didn’t include many of the advanced features available in Hibernate at the time, including Hibernate’s very powerful Criteria API. When JPA was first released, many organizations used both JPA and Hibernate together. Developers would call upon proprietary Hibernate APIs, such as the HibernateSession within their code, while at the same time, they would decorate their JavaBeans and POJOs with JPA-based annotations to simplify the mapping between the Java code and the relational database in use. In doing so, organizations took advantage of useful features in the standard API, and simultaneously had access to various Hibernate functions that weren’t yet standardized.

Hibernate and JPA are two complimentary Java technologies.

Advantages of Hibernate vs JPA

Even today, it’s possible for there to be advanced mapping features baked into the Hibernate framework that aren’t yet available through the JPA specification. Because JPA is guided by the JCP and JSR process, it’s often a slow and methodical process to add new features. However, since the JBoss team that manages the Hibernate project isn’t bound by these sorts of restrictions, they can make features available much faster through their proprietary APIs. Some important features that were implemented by Hibernate long before the JPA specification caught up include:

• Java 8 Date and Time support
• SQL fragment mapping
• Immutable entity types
• Entity filters
• SQL fragment matching
• A manual flush mode
• Second level cache queries
• Soft deletes

But, despite the fact the Hibernate is often quicker at the draw when it comes to introducing new and advanced features, the JPA 2.0 release almost closed the gap between the two. It would be difficult for any software developer to develop applications with the proprietary API, when the JPA specification almost always provides equivalent functionality.

And if one of those advanced Hibernate features is required, you can always write code that bypasses JPA and calls the Hibernate code directly, which completely eliminates the need to ever choose sides in the JPA and Hibernate debate.