Recently we had a very healthy debate at work on the topic JPA VS Hibernate similar to the chicken or the egg causality dilemma which is commonly stated as "which came first: the chicken or the egg?".
Few people are in favor of JPA came first whereas few are in favor of Hibernate. Both the team have their own arguments to substantiate their claim. Let's hear out those arguments first because you might find it interesting as well as logical. After that, we would jump on the final verdict.
If you have a basic idea about JPA and Hibernate then skip point (1) and directly jump to point (2).
We had a very healthy discussion among Team A & Team B around this topic and their arguments seem quite logical and promising. But we haven't reached to any conclusion yet so we switched to Google in search of our pursuit and found that the verdict was in favor of Team B.
The final release date of the JPA 1.0 specification was 11 May 2006 as part of Java Community Process JSR 220 whereas Hibernate initial release was 23 May 2001. [Reference from Wikipedia].
On further research, we came to know that 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 them have more or less very similar APIs and obviously serving the exact same purpose. But, it's very difficult to switch between these ORM implementations. The goal of JPA was to standardize how Java applications performed ORM.
Our research cleared some more doubts, misunderstanding and misconception about JPA and Hibernate. If you are interested in those then bear with us some more time.
No one needs to choose between Hibernate and JPA. One either chooses to use JPA or not. And if one does choose to use the JPA to interact with their relational database systems, they would choose between the various implementations.
Few people are in favor of JPA came first whereas few are in favor of Hibernate. Both the team have their own arguments to substantiate their claim. Let's hear out those arguments first because you might find it interesting as well as logical. After that, we would jump on the final verdict.
If you have a basic idea about JPA and Hibernate then skip point (1) and directly jump to point (2).
1. What are JPA and Hibernate?
- JPA is a specification whereas Hibernate is Red Hat’s implementation of the JPA specification.
- There is only one JPA specification. But, there are many different implementations like Hibernate, TopLink, EclipseLink, OpenJPA, DataNucleus.
- 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. For example, Development of a maintenance release as JPA 2.2 was done under JSR 338. The maintenance review was approved on 19 June 2017. Just look at the participant's list below who involved in the evolution of the API:
2. The Arguments
Assumption: [Team A - JPA came first, Team B - Hibernate came first]
Team A: JPA came first. Just tell me, have we developed any piece of software till now where we haven't discussed it's design, architecture before starting the actual development or implementation? Don't we keep guidelines, best practices, industry & organization-specific conventions, design patterns, constraints in the back of our head before actually jumping on the implementation?
JPA is a specification which means it provides a set of documented requirements, designs (APIs, kind of Interface) that must be satisfied when anyone builds an implementation for persisting, reading, and managing data from our Java object to relational tables in the database. Using this specification only i.e. Java Persistence API(JPA), one could develop any implementation.
Based on the design, we implement the piece of software right? Also, we all know that design comes before development in SDLC. JPA is a design, and Hibernate is the implementation based on that design.
Now you decide yourself, which came first.
JPA is a specification which means it provides a set of documented requirements, designs (APIs, kind of Interface) that must be satisfied when anyone builds an implementation for persisting, reading, and managing data from our Java object to relational tables in the database. Using this specification only i.e. Java Persistence API(JPA), one could develop any implementation.
Based on the design, we implement the piece of software right? Also, we all know that design comes before development in SDLC. JPA is a design, and Hibernate is the implementation based on that design.
Team B: Hibernate and other ORM tools were already present there before JPA came in the picture. If you really understand the reason Why JPA was invented in the first place? then you would automatically agree with our point. Tell me what do you think about the benefits that JPA brings on the table?
You said it right and articulated it in a nice manner
1) It's a common standard that any ORM solution provider adheres to.
2) vendor/implementation-neutrality and compatibility -If one uses the standard JPA while development, then one is keeping their options open to switch to other JPA implementations.
Because of these benefits, we are saying Hibernate came first. It's another way around.
Initially, there were many ORM tools having more or less similar APIs and serving the exact same purpose. But, it's very tedious and difficult to switch between these ORM implementations as they are not following any common standards. To address this difficulty, JPA came in the picture whose goal was to standardize how Java applications performed ORM.
You said it right and articulated it in a nice manner
1) It's a common standard that any ORM solution provider adheres to.
2) vendor/implementation-neutrality and compatibility -If one uses the standard JPA while development, then one is keeping their options open to switch to other JPA implementations.
Because of these benefits, we are saying Hibernate came first. It's another way around.
Initially, there were many ORM tools having more or less similar APIs and serving the exact same purpose. But, it's very tedious and difficult to switch between these ORM implementations as they are not following any common standards. To address this difficulty, JPA came in the picture whose goal was to standardize how Java applications performed ORM.
The Verdict
The final release date of the JPA 1.0 specification was 11 May 2006 as part of Java Community Process JSR 220 whereas Hibernate initial release was 23 May 2001. [Reference from Wikipedia].
On further research, we came to know that 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 them have more or less very similar APIs and obviously serving the exact same purpose. But, it's very difficult to switch between these ORM implementations. The goal of JPA was to standardize how Java applications performed ORM.
Our research cleared some more doubts, misunderstanding and misconception about JPA and Hibernate. If you are interested in those then bear with us some more time.
Misunderstanding
Two most common misunderstandings:
- Comparing JPA and Hibernate: Ask yourself, can we compare two different entities? If your answer is No then why are we comparing JPA and Hibernate in the first place? Because JPA is the specification whereas Hibernate is an implementation. Mind it, because of Hibernate’s popularity, many people still continuing to use the term Hibernate when they really meant JPA.
- One has to choose between JPA or Hibernate: Gone are days(early JPA release) when the choice between JPA and Hibernate was a legitimate decision for any technical architect to take. Now all of the functionality provided by Hibernate can simply be accessed through the JPA API(latest release JPA 2.2 closed the gap between two). But be aware and informed, it might happen even today that, there are advanced features baked into the Hibernate framework that aren’t yet available through the JPA specification because of two reasons:
- JPA is guided by the JCP and JSR process, it’s often a slow and time taking process to add new features.
- Hibernate project isn’t bound by these sorts of restrictions, they can make features available much faster through their proprietary APIs.
We would say why don't we leverage the advantage of both JPA and Hibernate but the questions is how? - One could always write code that bypasses JPA and calls the Hibernate code directly. We might be already doing this in actual practice. For example: Developers could 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.
No one needs to choose between Hibernate and JPA. One either chooses to use JPA or not. And if one does choose to use the JPA to interact with their relational database systems, they would choose between the various implementations.
Happy Learning! Hoping that if you are having the same misunderstanding as ours then this write up would surely help you to clear your dilemma.
No comments:
Post a Comment