This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
as the name - Java Persistence API - suggests JPA is just the API and specification. The idea behind this is that you can use different implementations as long as they are compliant to the spec. Hibernate is one possible persistence provider for the JPA (although Hibernate can be used without JPA). This way if you create code which only relies on the parts of the JPA without using specific features from a persistence provider it's very easy to switch between different implementations. Another popular alternative for example is TopLink.
I hope this makes it clearer ;-)
Joined: Jan 30, 2009
Hi Marco , Thanks for your time .
You mean to say is that JPA is only an API and not programming in which we can embed any ORM layer like Hibernate ,TopLink----etc for performing CRUD operations??(Please correct me if i am wrong here)
so what i understand is that EJB2.1 is a failure and Sun has provided the JPA specs , upon which Hibernate is built on ??
@Sandeep: Of course there are Alternatives to JPA ;-)
@RaviNada: I think you got me wrong. JPA of course uses the said ORM tools under the hood and of course it provides the known CRUD operations to you. Just have a look at the API documentation for the class EntityManager!
There are different reasons why the persistence part was moved to a separate specification and is no longer an integral part of the EJB specification. One reason is that you can use JPA now in standalone applications without EJBs or an EJB container at all. But the main thing here is that the JPA provides a standardized interface to different persistence providers so that you are not forced to use a specific vendor and switch easily between them.
Joined: Jan 30, 2009
i am getting little bit by the help provided by you.
I understand your problem. So I'll try to explain it better :-)
The JPA and Hibernate give you almost the same functionality and both are very similar in their usage. The JPA was created to combine and standardize the best ideas of famous ORM tools. For this it's obvious why JPA isn't very much different from Hibernate. As far as I know the Hibernate team (and others) were quite involved in creating the specification and API.
So the question isn't which can do your work better because they can almost do the same things. After all you could use Hibernate as an implementation provider for JPA. As I said the JPA is only the API and specification! It uses Hibernate or another ORM to do all the work! And because JPA is an official standard all compliant containers should support it out of the box without tying you to a specific vendor.
Because the usage of JPA is very easy and similar to Hibernate it's probably better to use JPA in favor of Hibernate because you're free to switch to another implementation later without having to learn everything from scratch. I'm not an expert in persistence questions and I must confess that I only used Hibernate as persistence provider for the JPA but the only reason I see today for using Hibernate without JPA is because you may need a feature which only "plain" Hibernate can provide and which is not part of the JPA. Spontaneously I don't have any idea which features these could be but I'm sure there are enough Hibernate experts here at the JavaRanch who can exactly tell you which features are only available when using Hibernate directly - without JPA.
And to your last question: Hibernate IS enough but in my opinion with JPA you gain the said advantages without having to do more work or learning a lot of new things!