There was a bit of a backlash when the last tutorial on JPA and Hibernate 3.5 was posted here at TheServerSide.com. Why would we use the Hiberante API instead of just using the Java Persistence API, and thus shield ourselves from the underlying implementation? Well, the reason was simple. We wanted to demonstrate both approaches so you could compare them side by side!

Tutorial I: Configuring Your Development Environment for Hibernate with JPA
Tutorial II: Hibernate & JPA Basics - Performing CRUD Operations

So, here's the follow-up tutorial that demonstrates how to perform the exact same CRUD based operations that were done in the previous tutorials, but instead, without any reference to the Hibernate API. It's a great way to compare the two approaches, and if you've been using Hibernate, and are thinking about migrating your code to a fully JPA compliant implementation, this will give you a bit of insight into what is involved. Enjoy!

Hibernate without Hibernate? Using Hibernate as Your JPA 2.0 Implementation Provider

********************

How to Learn Hibernate
Hibernate Made Easy WebSite
Video Tutorials on Learning Hibernate
Recommended Books for Learning Hibernate
Check out this updated Tutorial for Spring 3 as well.

And to give visibility of some other JPA providers, so people don't get the impression that there is only one, the following all provide complete JPA(2) implementations :-

DataNucleus AccessPlatform, EclipseLink JPA, OpenJPA.

It is likely that there are others who partially or completely implement the JPA2 spec, so do your research before choosing.

--Andy (DataNucleus)

Hey Andy. Sorry about the editor. I tried to clean up the mess that was created there.

Indeed, Hibernate is pretty hot these days, and I simply have more people in my circle that can help me get tutorials on the subject, so I apologize for any lean towards the JBoss/Hibernate stuff.

The nice thing about the JPA tutorial is that it's valid for any of these JPA providers that you've mentioned.

You know, I'd love to have a tutorial on DataNucleus that does essentially the exact same setup tasks as we did in the first Hibernate tutorial. If you know anyone that might be interested in taking an hour or two to write it up, I'd love to feature it at the top of the news thread.

-Cameron McKenzie

Seriously, "shield ourselves from the underlying implementation"? Somehow I think PHP developers would laugh at this. Java needs a big dose of "just get it done".

Thanks for the tutorial though. It was pretty good, but was fine just using Hibernate direct since it offers more features and functionality than just JPA. I don't think anyone using hibernate would go with a pure JPA implementation.

>>I think PHP developers would laugh at this

You know, those PHP folks give us Java people a thing or two to laugh about from time to time as well!

>>I don't think anyone using hibernate would go with a pure JPA implementation.

Indeed, you make a good point. Tthe inherent problem with standards is just that - it's a standard, and it's what everyone can agree upon. But there's always people that want to go beyond simply what everyone has agreed upon, and in the ORM community, that often means going beyond simply what JPA provides, and using the additional facilities of the underlying ORM framework, whatever that framework might be.

Indeed, you make a good point. Tthe inherent problem with standards is just that - it's a standard, and it's what everyone can agree upon. But there's always people that want to go beyond simply what everyone has agreed upon, and in the ORM community, that often means going beyond simply what JPA provides, and using the additional facilities of the underlying ORM framework, whatever that framework might be.

Everyone? No one asked me. If they had I would have said, make the standard like Hibernate from end to end. I guess the real question is, if the JPA standard is a subset of Hibernate on which it was based, then where is the value in it?

Hahaaaa.

I've just waded through a set of "massive" PHP apps (security review). It supposedly well designed apps.

It's the worst piece of shit I've ever seen. No wonder php programmers invariably comes across as less bright than a moose on lsd.

Hahaaaa. I've just waded through a set of "massive" PHP apps (security review). It supposedly well designed apps.It's the worst piece of shit I've ever seen. No wonder php programmers invariably comes across as less bright than a moose on lsd.

The same can be said and sometimes is of Java developers. Security is literally a myth IMO anyway. You can put your standard set of measure in place and call an app "secure". Then it will remain secure until the first person breaks into it.

Point here was IT always wraps itself up into a tight wad of security while increasing time to market and causing pains and nightmares of developers trying to get their job done. It's a waste of time... unless you're corp is in the security business.

The lesson all of us Java devs can take away from PHP is, they get the job done, period. There's no WordPress, Durpal, Wikia, or osCommerce for Java. There are some apps with partial functionality but that's it. Get 5 Java devs in a room to build a web app and ask them what to use on the front end, and you'll get 5 different answers.

That needs to change.

Im using Hibernate-JPA (3.2 version).

My reason is simple. JPA is just a set of interfaces, and a set of rules to be follow by the provider. So, if I have to choose a good JPA provider, I would would the choose the JPA provider that has the best ORM in the market and the best documentation (IMO of course).

Im using Hibernate-JPA (3.2 version).

My reason is simple. JPA is just a set of interfaces, and a set of rules to be follow by the provider. So, if I have to choose a good JPA provider, I would would the choose the JPA provider that has the best ORM in the market and the best documentation (IMO of course).

 

I tried to follow that rule about 8ish years ago. I've been in the industry 20 years, and I have never once seen anyone make a major move like swapping their database, JPA, or other core frameworks. Even when you do, it's never 100% smooth, like the java myth of write once, run anywhere.

I know in the past I get tunnel vision to looking at what I do from only a technical standpoint. My boss's boss doesn't care about the technical issues. He just wants a button for customers to click to place the order. It's the "what is best for the business" mentality why people break out of JPA and use Hibernate specific functions... just like java developers sometimes use stored procs with their JPA implementations.

Business needs > technical purity

Hi Cameron,

I'm glad to see this follow-up 'JPA only' tutorial :)
You're right by saying that comparing the two approaches side by side will help people migrate from the Hibernate API to the JPA API (I'm talking API, because we know Hibernate can stay as the JPA provider).
As you noted, this tutorial is valid for any JPA implementation: I ran your sample code without problem using EclipseLink.
And for those who want to use the advanced features of the underlying provider that are not part of the JPA spec, there is always the unwrap method of the EntityManager that gives access to the provider specific API.

Waiting for the next tutorial, adding the Spring framework to the stack :)

Keep them coming,

Christian Gossart.