Closed. This question is opinion-based. It is not currently accepting answers.
Closed 4 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I understand that JPA 2 is a specification and Hibernate is a tool for ORM. Also, I understand that Hibernate has more features than JPA 2. But from a practical point of view, what really is the difference?
I have experience using iBatis and now I'm trying to learn either Hibernate or JPA2. I picked up Pro JPA2 book and it keeps referring to "JPA provider". For example:
If you think a feature should be standardized, you should speak up
and request it from your JPA provider
This confuses me so I have a few questions:
Using JPA2 alone can I fetch data from DB by simply annotating my POJO's
Is JPA2 supposed to be used with a "JPA Provider" e.g TopLink or Hibernate? If so, then what's the benefit of using JPA2 + Hibernate as compared to JPA2 alone, or compared to Hibernate alone ?
Can you recommend a good practical JPA2 book. "Pro JPA2" seems more like a bible and reference on JPA2 (It doesn't get into Queries until the later half of the book). Is there a book that takes a problem/solution approach to JPA2?
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:
Hibernate
TopLink
JDO
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:
extended identifier generators (hi/lo, pooled, pooled-lo)
transparent prepared statement batching
customizable CRUD (#SQLInsert, #SQLUpdate, #SQLDelete) statements
static or dynamic collection filters (e.g. #FilterDef, #Filter, #Where) and entity filters (e.g. #Where)
mapping properties to SQL fragments (e.g. #Formula)
immutable entities (e.g. #Immutable)
more flush modes (e.g. FlushMode.MANUAL, FlushMode.ALWAYS)
querying the second-level cache by the natural key of a given entity
entity-level cache concurrency strategies
(e.g. Cache(usage = CacheConcurrencyStrategy.READ_WRITE))
versioned bulk updates through HQL
exclude fields from optimistic locking check (e.g. #OptimisticLock(excluded = true))
versionless optimistic locking (e.g. OptimisticLockType.ALL, OptimisticLockType.DIRTY)
support for skipping (without waiting) pessimistic lock requests
support for Java 8 Date and Time
support for multitenancy
support for soft delete (e.g. #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.
JPA : is just like an interface and have no concrete implementation of it to use functions which are there in JPA.
Hibernate : is just a JPA Provider which have the implementation of the functions in JPA and can have some extra functions which might not be there in JPA.
TIP : you can use
*combo 1* : JPA + JPA Provider(Hibernate)
*combo 2* : only Hiberante which does not need any interface
Combo 1 : is used when you feel that your hibernate is not giving better performance and want to change JPA Provider that time you don't have to write your JPA once again. You can write another JPA Provider ... and can change as many times you can.
Combo 2 : is used very less as when you are not going change your JPA Provider at any cost.
Visit http://blog-tothought.rhcloud.com//post/2, where your complete confusion will get clear.
JPA is the interface, Hibernate is one implementation of that interface.
JPA is a specification to standardize ORM-APIs. Hibernate is a vendor of a JPA implementation. So if you use JPA with hibernate, you can use the standard JPA API, hibernate will be under the hood, offering some more non standard functions.
See http://docs.jboss.org/hibernate/stable/entitymanager/reference/en/html_single/ and http://docs.jboss.org/hibernate/stable/annotations/reference/en/html_single/
JPA is just a specification.In market there are many vendors which implements JPA. Different types of vendors implement JPA in different way. so different types of vendors provide different functionality so choose proper vendor based on your requirements.
If you are using Hibernate or any other vendors instead of JPA than you can not easily move to hibernate to EclipseLink or OpenJPA to Hibernate.But If you using JPA than you just have to change provide in persistence XML file.So migration is easily possible in JPA.
JPA is an API, one which Hibernate implements.Hibernate predates JPA. Before JPA, you write native hibernate code to do your ORM. JPA is just the interface, so now you write JPA code and you need to find an implementation. Hibernate happens to be an implementation.
So your choices are this:
hibernate, toplink, etc...
The advantage to JPA is that it allows you to swap out your implementation if need be. The disadvantage is that the native hibernate/toplink/etc... API may offer functionality that the JPA specification doesn't support.
While JPA is the specification, Hibernate is the implementation provider that follows the rules dictated in the specification.
Java - its independence is not only from the operating system, but also from the vendor.
Therefore, you should be able to deploy your application on different application servers.
JPA is implemented in any Java EE- compliant application server and it allows to swap application servers, but then the implementation is also changing. A Hibernate application may be easier to deploy on a different application server.
JPA is a specification that you implement in your data layer to perform db opertations, OR mappings and other required tasks.
Since it is just a specification, you need a tool to have it implemented. That tool can be either Hibernate, TopLink, iBatis, spring-data etc.
You don't necessarily require JPA if you are using Hibernate in your Data Layer. But if you use JPA specification for Hibernate, then it will make switching to other ORM tools like iBatis, TopLink easy in future, because the specification is common for others as well.
*(if you remember, you do import javax.persistence.*; when you use annotations for OR mapping (like #Id, #Column, #GeneratedValue etc.) in Hibernate, that's where you are using JPA under Hibernate, you can use JPA's #Query & other features as well)
JPA is a Java API specification which describes the management of relational data in applications using Java Platform. where as Hibernate is a ORM (Object Relational Mapping) library which follows JPA specification.
You can think JPA as a set of Rules which is implemented by Hibernate.
JPA is JSR i.e. Java Specification Requirement to implement Object Relational Mapping which has got no specific code for its implementation. It defines certain set of rules for for accessing, persisting and managing the data between Java objects and the relational databaseWith its introduction, EJB was replaced as It was criticized for being heavyweight by the Java developer community.
Hibernate is one of the way JPA can be implemented using te guidelines.Hibernate is a high-performance Object/Relational persistence and query service which is licensed under the open source GNU Lesser General Public License (LGPL) .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.
JPA is just a specification which needs concrete implementation. The default implementation provided by oracle is "Eclipselink" now. Toplink is donated by Oracle to Eclipse foundation to merge with eclipselink.
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. Hibernate is super set of JPA with some extra Hibernate specific functionality. So application 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, which is an extension of Kodo implementation.
JPA vs Hibernate
I try to explain in very easy words.
Suppose you need a car as we all know their are several A class manufacturer like MERCEDES, BMW , AUDI etc.
Now in above statement CAR(is a specification) as every car have common features like thing with 4 wheels and can be driven on road is car...so its like JPA.
And MERCEDES, BMW , AUDI etc are just using common car feature and adding functionality according to their customer base so they are implementing the car specification like hibernate , iBATIS etc.
So by this common features goes to jpa and hibernate is just an implementation according to their jboss need.
1 more thing
JPA includes some basic properties so in future if you want to change hibernate to any other implementation you can easily switch without much headache and for those basic properties includes JPA annotations which can work for any implementation technology, JPQL queries.
So mainly we implement hibernate with JPA type technology just for in case we want to switch our implementation according to client need plus you will write less code as some common features are involved in JPA.
If someone still not clear then you can comment as i m new on stack overflow.
Thank you
JPA is just a specification while Hibernate is one of the JPA provider i.e hibernate is implementing various things mentioned in JPA contract.
JPA or Java Persistence API is a standard specification for ORM implementations whereas Hibernate is the actual ORM implementation or framework.
JPA is Java Persistence API. Which Specifies only the specifications for APIs. Means that the set of rules and guidelines for creating the APIs. If says another context, It is set of standards which provides the wrapper for creating those APIs , can be use for accessing entity object from database. JPA is provided by oracle.When we are going to do database access , we definitely needs its implementation. Means JPA specifies only guidelines for implementing APIs. Hibernate is a JPA provider/Vendor who responsible for implementing that APIs. Like Hibernate TopLink and Open JPA is some of examples of JPA API providers. So we uses JPA specified standard APIs through hibernate.
Figuratively speaking JPA is just interface, Hibernate/TopLink - class (i.e. interface implementation).
You must have interface implementation to use interface. But you can use class through interface, i.e. Use Hibernate through JPA API or you can use implementation directly, i.e. use Hibernate directly, not through pure JPA API.
Good book about JPA is "High-Performance Java Persistence" of Vlad Mihalcea.
Related
Till now I have a understanding that JPA is a specification and Hibernate is ORM tool based on that specification and we can have different implementations of JPA. But I could not understand how is it possible then that JPA 2 doesnot supports java.time.Instant but Hibernate 5.2x supports it.
I have read this question why-jpa-does-not-support-java-time-instant but it doesn't have proper answers and doesn't talks how hibernate is able to provide support for Instant being a JPA specific implementation.
JPA is just a specification - it's a set of interfaces to provide common API. It describes the access to relational database to help developers manage multiple dbms vendors. There are multiple implementations of JPA, the reference is EclipseLink developed under Eclipse Public License. In other words it's a standard, like SQL-92 or SQL:2006. Databases that claim to support given standard can implement own features outside it to make data access easier.
In order to use JPA, we need an implementation. Besides EclipseLink the most common are Hibernate, OpenJPA and DataNucleus. All of them support JPA 2.2.
They implement the JPA specification but also provide additional functionalities to overcome some of JPA's shortcomings. Those functionalities are the main difference between implementations and make the code specific i.e. using, for example, Hibernate follows in code changes needed to be done when changing JPA specification. Only when using JPA we can switch between implementations. However I have never seen any project, that changed JPA vendor.
I'm new to JPA, and i understands that JPA is an interface that Hibernate and eclipse link are implementing..
can i implement it myself? or use JPA without Hibernate or eclipse link ?
all the tutorials and examples I've seen regards one of the implementations, but as for this answer: What is a JPA implementation?
If you want your application to be portable, use only JPA.
how can I use only JPA ? do someone know for such a tutorial to write my own PersistenceProvider(i thinks that's what i need to do..)
Thank you.
You should not build your own JPA implementation, but use the JPA API and rely on an implementation such as Hibernate or EclipseLink. As long as you'll use classes/interfaces in the javax.persistence namespace (or package if you prefer), you'll be strictly using JPA.
The only reason to implement JPA is that you are the provider-manufacturer of an enterprise-level ORM such as Hibernate or iBatis.
JPA is a standard wrapper for the existing ORM products, it is an option available to you to use it as a wrapper for your ORM. It can't be used (as far as I know) appart from an ORM.
That in the case that your decision is to use an ORM for your database access. You must consider every option: does JDBC stand-alone suit you for your job? Would an object abstraction layer bring anything to your application? Is there any legacy condition that you must consider (for example, tons of code in PL/SQL that hide the tables from you) that would make you discard an ORM?
I am using Hibernate in our projects and annotation based configuration for Hibernate Domain Pojo Objects. For Annotations based configuration we have two options
JPA based annotations using javax.persistence.*
Use Hibernate Native Annotations org.hibernate.annotations.*
Currently we use JPA based annotation configuration for our POJO files and Hibernate native API like SessionFactory, Session, etc to open session and perform DB operations.
I have these questions:
Is there any problem mixing both JPA annotations and use Hibernate
native API?
This link explains one such issue
(cascade-jpa-hibernate-annotation-common-mistake)
Please provide your expertise, which type of annotations to use
JPA
Hibernate native
Mix both of them?
Hibernate provides one of the JPA implementations. If you use purely JPA in your code, you are free to change to a different implementation if a requirement arises. For example, EclipseLink/TopLink and OpenJPA are implementations which may be required for a different customer. A comprehensive list of implementations is here.
If you are compelled to use any exotic features provided by hibernate which are not in JPA specification, you should go for hibernate specific APIs in your code base. A related discussion from hibernate forum here.
We mixed some of these annotations since with the version of hibernate we were working those days, some features were not available on the JPA spec at that time. For instance to store a boolean value as a 'Y' or 'N' on th DB you have hibernate types you can use. But no such feature was available with the JPA spec at that time. I do not know about the status now. Also for orphan removal also those days JPA did not have the feature, but now i belive they provide an attribute called orphanRemoval on your cascade options. Also you have certain features such as #BatchSize to increase fetching performance with respect to bags. I am unaware if such features are available on the JPA spec yet.
In my experience, mixing and matching plus points from both would be beneficial given that you have no need of switching from one ORM to another.
I'm getting started with JPA, and I'm confused as to what exactly the JPA implementation(EclipseLink, TopLink, Hibernate, etc.) does.
I understand the theoretical role of JPA, but what is the purpose of the various implementations? Are there significant differences between these choices, as there is with say, DB connectors/drivers? Which is the best one for a beginner?
I'll probably go with EclipseLink because that is what most of the literature I've read uses.
JPA is just an API (hence Java Persistence API) that requires an implementation to use.
An analogy would be using JDBC. JDBC is an API for accessing databases, but you need an implementation (a driver jar file) to be able to connect to a database. On its own, without a driver, you cannot do anything with a database.
With JPA, as I said, you need an implementation, a set of classes that lie "below" JPA, and such an implementation will do what you want.
Your application uses the JPA API (this wording is a bit cubersome, but I hope you get the idea), which then communicates with the underlying implementation.
Popular implementations include Hibernate, EclipseLink, OpenJPA and others.
Every one of them implement the JPA API, so if you use only JPA, every implementation should act the same.
But! The functionality provided by these implementations might go beyond the standard JPA API.
If you want to use this particular functionality, you will have to use vendor specific API that will not be compatible with others.
For example, even though JPA defines the #Id annotation with ID generation options, when using Hibernate, you can use also #org.hibernate.annotations.GenericGenerator for Hibernate specific generation strategies.
Using this annotation will not work unless you're using Hibernate as the underlying implementation.
The bottom line is: JPA is the "least common denominator" which every vendor implements, and every implementation might have some more advanced features that aren't standard.
If you want your application to be portable, use only JPA. If you are sure you won't change your mind later on and switch implementations, use JPA + vendor specific features.
It's the same as Java, it has a specification (Java SE, Java EE) and implementation, most people use the reference implementation (By Sun / Oracle) which is a blueprint for others to make their own "better" and "advanced" implementation of the specification (APIs, Interfaces and documentation / JavaDoc if you need a one word definition, although it is much more than that)
So the Java / JDK you are most likely using is just an implementation (that is very popular). There are many more implementations out there, some have more Garbage Collection configuration options, some claim to be faster, and some are just not worth using.
So the implementation basically does everything, it has the code, where the JPA is an API (implied by it's name, Java Persistance API) e.g. again, more about interfaces and documentation than real implentation of the interface.
Think of it as the abstact class that Hibernate's JPA implementation / EclipseLink extends / implements
Regarding JPA, as opposed to Hibernate which has a single implementation, the idea is to decouple the interface from the implementation, so that the "best" implementation will win and that everyone can participate in the game, not just the interface creator.
This allows for instance for Google App Engine to support JPA, as it just needs to follow an API (DataNucleus is the implementation) if it has to use Hibernate, it would have required to modify the Hiberanate release to support Google's Big Table format (the fact that JPA in GAE is not that great is another story)
JPA itself is just a specification, not a product; it cannot perform persistence or anything else by itself. JPA is just a set of interfaces, and requires an implementation. There are open-source and commercial JPA implementations to choose from and any Java EE 5 application server should provide support for its use. JPA also requires a database to persist to.
The Java Persistence API (JPA) is a Java programming language application programming interface specification that describes the management of relational data in applications using Java Platform, Standard Edition and Java Platform, Enterprise Edition.
The Java Persistence API originated as part of the work of the JSR 220 Expert Group of the Java Community Process. JPA 2.0 was the work of the JSR 317 Expert Group.
So, JPA provides set of interfaces which must be implemented. There are always reference implementations available for language specifications , in this case EclipseLink is the reference implementation.
Hibernate on the other hand, does implement JPA specification but it also has it's own native API.
For Example :
Say you designed an Authentication specification which contains only one interface :
public interface AccessAuthenticator {
public boolean verifyAccess(String username,String saltedPassword);
}
Now this specification contains only one interface and one single method.
In order to use this specification(more precisely the verifyAccess( ) method) you must have an implementation.
There can be many implementations for this spec. for example, some organization may provide it's implementation for authentication to it's own servers. you must have that implementation in order to connect to the organizations server (There may be some native API involved).
One more aspect of providing a specification is that you don't actually use the concrete implementation of anything , so today say you are using hibernate to connect to your database but tomorrow some better ORM comes in picture that implements JPA spec, then all you need to do is change the dependency in your project (in simple words replace the implementation JAR file/Edit the pom file).
JPA is a Java API specification which describes the management of relational data in applications using Java Platform. You can think JPA as a set of Rules, and hence it can not do any concrete work for you but helps you to standardize your implementation.
So you need concrete implementation which will implements JPA (set of rules). Hibernate, OpenJPA are few of famous JPA implementations.
I learnt JPA for ORM. Now I am asked to use Hibernate as my provider.
If I start with Hibernate it is going down in different concept.
Please say me How can I relate JPA and hibernate together.
JPA reduces my Java code into simple code for persisting Objects.
Now what does hibernate help JPA and what does it provide.
Anyone please explain in simple.
As Pascal answered here
JPA is just an API. To use JPA, you need an implementation of this API and such implementations are called persistence providers (EcliseLink, Hibernate, OpenJPA)
Hibernate is not another concept; it is just one of many JPA implementations. Another would be EclipseLink. If you and the implementations keep to the specification then switching the implementation is just a matter of changing a couple of lines in your persistence.xml (e.g. the <provider> tag and implementation specific properties). At least in theory...
JPA is an API specification for persisting objects. It defines a SQL like query language, and annotations for defining entities and relationships.
Hibernate is an implementation of JPA that has various extensions as well as a legacy API and query language. As long as you don't use any of the extensions of Hibernate and stick with the JPA API you can more or less treat it interchangeably with other JPA implementations such as OpenJPA, TopLink etc.