0

I work to a project that it has installed Spring, Hibernate and JPA.

I have read tutorials about Hibernate and JPA and the big picture is that JPA is an interface, and Hibernate is the implementation of JPA.

But why to use JPA, with what it helps me? What are the differences between JPA and Hibernate. First, i thought that annotations in POJO classes are from JPA, but no, they are from Hibernate Annotations.

So, the big question is, for what is good JPA? Thanks!

fabby
  • 131
  • 3
  • 15
  • 1
    Clearly search is down today. https://stackoverflow.com/questions/9881611/whats-the-difference-between-jpa-and-hibernate – Neil Stockton Mar 30 '17 at 15:01

2 Answers2

3

The root reason for JPA to exist lies within the larger Java Enterprise specification. There was a growing need for a standardised ORM API to be part of the JavaEE 5 specification for standardisation across Java enterprise containers. That's it - that is why JPA exists and why existing ORM packages such as Hibernate do their best to implement it to the letter.

The net gain is quite simple; any Java Enterprise container (JBoss Wildfly, Weblogic, etc.) will support the JPA specification and will have an implementation for it built-in. Thus if you build an application or library and use only the JPA API in your code, you don't even have to package Hibernate or any other ORM with your application - it will during runtime just use whatever ORM the container provides.

Historically this wasn't usually possible because you'd still end up needing to add ORM specific configuration properties, so you at least needed to be aware of what ORM would be available on deployment to cater towards it. But since JPA 2.0 and 2.1 most of the common and uncommon configuration options have been standardised.

Long story short: if you're deploying to a JavaEE (or Spring Boot) container then using JPA is simply a good idea because it is readily available and is the standard (for object relational mapping).

If you're not going to be deploying to a JavaEE container and are going to be packaging an ORM with your application - well then you're even more free to do what you want. Just be aware that you wouldn't be the first to kick themselves when they're at a later point in time porting over code or maintaining a code base with mixed API usage.

Gimby
  • 5,095
  • 2
  • 35
  • 47
  • ok, so from all the replies, i understand that the only difference is the import of javax.persistence instead of org.hibernate, right? And, like i said, is only an interface, and therefore you can change hibernate with other ORM. And if, for a case, where i create a java persistence class, where i import on the top javax.persistence and inside i have a annotation like @Entity, where the JVM knows that is a annotation from hibernate, and will take the logic from there? – fabby Mar 30 '17 at 15:39
  • @fabby not exactly, but you're thinking in the right direction. I wouldn't worry too much about the gritty details of how it works under the hood, its more fruitful to just focus on how it works from the outside. The key is the persistence.xml configuration file; I'd put some reading into all the options you have available there. – Gimby Mar 31 '17 at 13:08
2

Java Persistence Architecture (JPA) is a standard for Java object-relational mapping solution like Hibernate, TopLink, etc. Hibernate is a particular implementation of JPA.

You should be using JPA annotations so you aren't locked into Hibernate.

Make sure you are using JPA for a good reason. You might not need it. JDBC might be enough for your needs.

Community
  • 1
  • 1
duffymo
  • 305,152
  • 44
  • 369
  • 561