JPA vs Spring JPA vs Spring Data JPA vs Hibernate

[swaraj gupta]

Hi,

I have been going through lots of tutorials and blogs available over internet regarding JPA. And after reading a handful of blogs on internet, I am badly confused between these terms.

Could you please help me out with my confusion that I can move ahead with my learning?

1. JPA
2. Spring JPA
3. Spring Data JPA
4. Hibernate

Thanks

[Jesper de Jong]

JPA is the Java Persistence API, which is Java's standard API for object-relational mapping.

JPA is only an specification - you need an implementation of it to be able to use it. Hibernate is one of the most well-known and most used implementations of JPA, but there are others, such as EclipseLink JPA.

The Spring Framework is a large framework to help you write enterprise-grade software easier. It contains support for many Java technologies, including JPA.

The Spring Framework consists of a collection of projects, and one of these projects is Spring Data.

The goal of Spring Data is to make it easier to work with different kinds of databases, from traditional relational databases to NoSQL databases. Spring Data supports JPA via the Spring Data JPA subproject.

To write a program that uses JPA, you need at least a JPA implementation, such as Hibernate.

If you are using the Spring Framework for your application, you will most likely want to use Spring Data JPA together with Hibernate.

[swaraj gupta]

Thanks for your reply Jesper. But I am still a bit confused on the following points. If you could clarify or confirm my doubts here.

1. Is there any such thing exists, which is called 'Spring JPA'? or it is that some people used to abbreviate 'Spring Data JPA' as 'Spring JPA' only?

2. When we say:
   

The Spring Framework consists of a collection of projects, and one of these projects is Spring Data.

Can we say that:
2.1 'Spring Data' project of Spring is totally an independent project of Spring, and has nothing to do with JPA specification?
2.2 'Spring Data' is not an API specification?
2.3 'Spring Data' alone could be used for dao operations as we use Hibernate.

3.  

If you are using the Spring Framework for your application, you will most likely want to use Spring Data JPA together with Hibernate.

3.1 Does that mean 'Spring Data JPA' is a specification or api like JPA that we are using it together with Hibernate which is a JPA implementation?
3.2 In case if 'Spring Data JPA' is a specification or api like JPA then why 'Spring  Data JPA' api is written when JPA specification was already in place?


Thanks

[Jesper de Jong]

swaraj gupta wrote:1. Is there any such thing exists, which is called 'Spring JPA'? or it is that some people used to abbreviate 'Spring Data JPA' as 'Spring JPA' only?

I don't think there is a part of Spring that is called "Spring JPA". Maybe there are parts of Spring that support JPA and that are outside of Spring Data JPA, but I think it's probably what you think as well: people are saying "Spring JPA" when they really mean "Spring Data JPA".

swaraj gupta wrote:
Can we say that:
2.1 'Spring Data' project of Spring is totally an independent project of Spring, and has nothing to do with JPA specification?
2.2 'Spring Data' is not an API specification?
2.3 'Spring Data' alone could be used for dao operations as we use Hibernate.

2.1: No, Spring Data is not totally independent of Spring, it is a part of the Spring Framework and needs other parts of the Spring Framework. Spring Data itself indeed does not have anything to do with JPA, but Spring Data JPA (which is a part of Spring Data) of course does.

2.2: Spring Data is not an API specification.

2.3: If you are using Hibernate in a Spring project, you'll most likely want to use Spring Data JPA. Note that Spring Data by itself is just an umbrella project for different subprojects, one of which is Spring Data JPA (which is specifically meant for working with relational databases through JPA). Other Spring Data subprojects are for working with different other kinds of data stores (for example, several different kinds of NoSQL databases).

Spring Data by itself isn't a complete library. You'll want to use one of the Spring Data subprojects; which one, depends on what database you need to work with.

swaraj gupta wrote:
3.1 Does that mean 'Spring Data JPA' is a specification or api like JPA that we are using it together with Hibernate which is a JPA implementation?
3.2 In case if 'Spring Data JPA' is a specification or api like JPA then why 'Spring  Data JPA' api is written when JPA specification was already in place?

No, Spring Data JPA is not a specification that has a separate implementation. It is a support library to make working with JPA easier, and to integrate it with the rest of the Spring Framework.

JPA -> API specification
Hibernate -> implementation of the JPA API
Spring Data JPA -> support library to make working with JPA easier and integrate it with the rest of Spring

[Tim Holloway]

Let's see if I can help.

Java Persistence Architecture (JPA) is the standard Object Relational Model (ORM) architecture. There used to be others (for example, JDO), but they were vendor-specific and there was no universal standard. JPA is actually a part of the JEE Enterprise Java Beans (EJB) standard, but it can stand alone without requiring the full EJB functionality.

Hibernate was another ORM implementation back before JPA became standard, just like JDO was, although it was probably the most popular ORM system. ORM, incidentally, refers to a system where you map database tables to java classes and do your persistence by manipulating instances of those classes instead of, say, doing brute-force JDBC database I/O.

When EJB3/JPA became an official Sun standard, Hibernate adapted by providing an implementation known as Hibernate JPA. They continue to support legacy Hibernate functions, but you now could use the JEE standard with Hibernate under the hood as well.

So much (for the moment) for persistence.

The Spring Framework (or simply Spring, for short) is an Inversion of Control object management system. In Inversion of Control (or IoC, for short), you don't "go out and get things". Instead, things are delivered to you automatically. Spring maintains object factories to produce object instances, but it can also inject automatically-created instances into selected JavaBeans (or JavaBean-like objects).

Spring is modular and it can wire together almost anything you can think of, including custom beans of your own devising. Modules include Spring Security, Spring Web, Spring scheduler services, and many more. However, one of the most commonly-used modules is the Spring Data module. Within Spring Data, there are several choices of persistence system. There's Spring JDBC to handle the dirty work of obtaining (and properly disposing) JDBC connections, there's a Spring Data for MongoDB and other noSQL DBMS's. There's Spring Data for Neo4J-organized data, as well as for systems like LDAP. The list goes on and on: http://projects.spring.io/spring-data/

But it's the Spring Data JPA subsystem that can make it easier to work with Hibernate JPA - it injects EntityManagers and provides data services specifically aimed at JPA. And, although Hibernate JPA is a common choice, Spring JPA works with other JPA systems as well. The abstractions that Spring and the JPA standard provide means that once, when I had a project using Apache OpenJPA as my persistence framework and that particular implementation couldn't do what I needed, all I had to do was make a few changes to my Maven POM file, add a few Hibernate-specific configuration options, and within a half-hour I was completely shifted from OpenJPA to Hibernate JPA.

[swaraj gupta]

Thank you Jasper and Tim for your replies and clearing up a lot of my confusion around JPA and its implementations.

I just tried to summarize the discussion here with the help of following points. kindly correct me if anything which I have stated here is not correct.


1. Java Application(Non Spring Application) + Hibernate: It's a tightly coupled Java application with Hibernate. And, in case tomorrow if it would be required to change the JPA implementation then we may need to make the changes in our java application code as well.

2. Java Application(Non Spring Application) + JPA(using JPA jar) + Hibernate: Here, ideally we should be using the method signatures provided by the JPA in our Java application. However, at runtime the JPA implementation provided by Hibernate will be used. And in case if it would be required to change the JPA implementation i.e. Hibernate then it will be required to change the Hibernate jars with some other JPA implementation jars only.

3. Spring Application(without JPA jar) + Hibernate: It's a tightly coupled Spring application with Hibernate and changing the JPA implementation may not be the matter of changing the jars only. It may be required to change the application code as well.

4. Spring Application + JPA(using JPA jar)+ Hibernate: Here, we should be using the method signatures provided by JPA. However, at runtime the JPA implementation provided by Hibernate will be used. But in case if it would be required to change the JPA implementation, then it will be required to change the hibernate jars with some other JPA implementation jars only.

5. Spring Application + Spring Data JPA(using spring-data-jpa jar): This combination can be used but will fail at runtime due to the absence of concrete JPA implementation in our classpath and hence can not be used to access the relational database.

6. Spring Application + Spring Data JPA(using spring-data-jpa jar) + Hibernate: Spring Data JPA is another layer of abstraction or wrapper on top of JPA with some additional interfaces which further reduces our coding efforts required to access any relational database. But under the hood Spring Data JPA uses the core interfaces of JPA having their implementation provided by any of its implementation like Hibernate, Toplink, EclipseLink etc.


Thanks

[Tim Holloway]

OK. I'll see if I can nail them down.

swaraj gupta wrote:Thank you Jasper and Tim for your replies and clearing up a lot of my confusion around JPA and its implementations.

I just tried to summarize the discussion here with the help of following points. kindly correct me if anything which I have stated here is not correct.


1. Java Application(Non Spring Application) + Hibernate: It's a tightly coupled Java application with Hibernate. And, in case tomorrow if it would be required to change the JPA implementation then we may need to make the changes in our java application code as well.

More or less. If you want to change from legacy Hibernate to Hibernate JPA (or a non-Hibernate JPA), that would require source code changes. Hibernate JPA is basically the same as non-Hibernate JPA.

Tim Holloway wrote:

2. Java Application(Non Spring Application) + JPA(using JPA jar) + Hibernate: Here, ideally we should be using the method signatures provided by the JPA in our Java application. However, at runtime the JPA implementation provided by Hibernate will be used. And in case if it would be required to change the JPA implementation i.e. Hibernate then it will be required to change the Hibernate jars with some other JPA implementation jars only.

Yes, the signatures are defined in the interface classes in the persistence-api JAR. That doesn't change. Only the implementation jar(s) that you use would change.

Tim Holloway wrote:

3. Spring Application(without JPA jar) + Hibernate: It's a tightly coupled Spring application with Hibernate and changing the JPA implementation may not be the matter of changing the jars only. It may be required to change the application code as well.

As in case 1, changing from one JPA system to another should require little or no changes. Changing from legacy Hibernate to Hibernate JPA would require code changes.

Tim Holloway wrote:

4. Spring Application + JPA(using JPA jar)+ Hibernate: Here, we should be using the method signatures provided by JPA. However, at runtime the JPA implementation provided by Hibernate will be used. But in case if it would be required to change the JPA implementation, then it will be required to change the hibernate jars with some other JPA implementation jars only.

Here again, only the JPA implementation jars would require changing. Mods to the code/setup are minor. The fact that Spring is involved makes no difference.

Tim Holloway wrote:

5. Spring Application + Spring Data JPA(using spring-data-jpa jar): This combination can be used but will fail at runtime due to the absence of concrete JPA implementation in our classpath and hence can not be used to access the relational database.

Actually, what Spring mostly does is supply/inject a persistence manager and wrap code with cleanup and standardized error handling. You still write JPA code, so you wouldn't even compile without a persistence API jar to prototype those functions.

Tim Holloway wrote:

6. Spring Application + Spring Data JPA(using spring-data-jpa jar) + Hibernate: Spring Data JPA is another layer of abstraction or wrapper on top of JPA with some additional interfaces which further reduces our coding efforts required to access any relational database. But under the hood Spring Data JPA uses the core interfaces of JPA having their implementation provided by any of its implementation like Hibernate, Toplink, EclipseLink etc.

And, see #5. Using Hibernate makes no difference.

[swaraj gupta]

Hello Tim,

Following what you have said as an answer to point # 5 and #6, I believe that following combination should work:

7. Spring Application + JPA(using JPA jar)+ Spring Data JPA(using spring-data-jpa jar) + Hibernate:  JPA to prototype the functions, Spring Data JPA for additional features of Repositories and a JPA implementation(Hibernate etc) as a concrete implementation to JPA.

Thanks