Hibernate 3.5 Without Hibernate: Migrating to the Java Persistence API

Here we look at using the Hibernate framework as our persistence mechanism, but only referencing the JPA libraries in our code. This way, your persistence code is not bound to the vendor that implements your persistence architecture.

In our first tutorial, we showed you everything you needed to do to configure a basic Java development environment that leverages Hibernate 3.5 and all of its associated and required libraries.

In our second tutorial, we decorated a very simple JavaBean with a few JPA 2.0 annotations, and then demonstrated how we could write some Hibernate code that consumes that JavaBean and performs some persistence magic for us.

Of course, no good deed goes unpunished at TheServerSide.com, so the initial feedback, like the response we got from Mr. Christian Gossart, was that it was a great tutorial, but it wasn't really a Hibernate vs JPA tutorial because it was using the Hibernate Session and other classes in the Hibernate API.

"Well, ... apart from the annotations on the GameSummary entity class ... this tutorial is Hibernate specific, and cannot be used with another JPA provider (be it EclipseLink or OpenJPA)." -Mr. Christian Gossart

Well, we aim to please here at TheServerSide.com, and we thought it would be neat to actually show you both sides of the coin; that is, performing data persistence with the Hibernate API, as we did in the previous tutorial, and now, showing how the same thing could be done using only the Java Persistence API, and no reference to Hibernate.

It should be noted that Hibernate is still the persistence provider. So, if you want to write and test this application, you need to follow all the same steps that were performed in the first tutorial that dealt with setting up a Hibernate development environment. The persistence implementation is all Hibernate under the covers. The only difference is that we're using the Java Persistence API to communicate with it.

Revisiting the JPA Annotated POJO

Here is what our JPA annotated GameSummary bean looks like. This is the exact code that was used in the two tutorials that were mentioned earlier. Notice that there is nothing Hibernate specific in this code; it's just a plain old Java object (POJO):

Now the offending code that contained all of the Hibernate API references was the little main method that I threw into that GameSummary class which performed some database functions. Here's what the runnable main method, which saved a GameSummary instance to the database, looked like when we leveraged the Hibernate API:

So, how could we do all of that without referencing the Hibernate API? Well, it's pretty simple, actually. It's almost an even swap between the JPA components and Hibernate components. Take a look at the following JpaRunner class, which does exactly the same thing as the main method above, with the exception of the fact that it doesn't reference the Hiberante API (note that this will not run successfully until you have configured a persistence.xml file, which we will do next):

As you can see, the JPA code is pretty similar to the Hibernate code, except instead of a Hibernate SessionFactory, you have the EntityManagerFactory, and instead of a Hibernate Session, you have an EntityManager. Other than that, the biggest difference between those two code snippets is the size of the font.

Now, there is one major change that needs to be made to the environment before the JPA code we just wrote can be tested: we need a persistence.xml file, which must be placed in a META-INF folder on the runtime classpath.

Again, the persistence.xml file really isn't that different from the hiberante.cfg.xml file, which is what you would expect, especially considering that it is the Hibernate and JDBC framework that is actually implementing the JPA specification for us behind the scenes. One thing that is important to note is the name given to the persistence-unit: PU.

<persistence-unit name="PU">

This name, PU, is the name used when you initialize your JPA EntityManagerFactory in your code:

Again, the logs reference Hiberante, because Hibernate JDBC is providing the implementation, but our code is completely shielded from any of those Hibernate related implementation details.

A Full Migration of the HibernateCrudRunner

The "grand finale" of the previous tutorial was a class called the HibernateCrudRunner, which created all sorts of transactions, and performed queries, updates, creates and delete operations on a very unsuspecting GameSummary instance, all using Hibernate. It's a big class, so I'm loath to reproduce it again here. Just scroll down to the bottom of this link and you'll see it. So, to really see how JPA works, I figured I'd reproduce that class in its entirety, but with nothing but JPA calls, and no reference to Hibernate. Here's how the JPA implementation of the HibernateCrudRunner looks:

You can see why I was loath to reproduce the original Java code for the class, as it is rather long. However, if you do compare the JPA implementation to the one that uses Hibernate, you'll see that the two are fairly similar. Sure, instead of a delete call, we have a remove call; and instead of a call to update or save, we have a call to persist, but otherwise, the two implementations are fairly similar.

And that's it! Okay, maybe that's not it, but it is a start. As you can see, if you have some experience with Hibernate, working with the Java Persistence API is fairly straight forward, and if you do port to JPA, you'll be able to move change your implementation provider without having to make any significant changes to your codebase.

***Update & Addendum***

I checked the budget, and apparently we have the funds to reproduce the HibernateCrudRunner in this tutorial. So, here it is, if you'd like to compare it with the JpaRunner above:

Join the conversation

2 comments

Register

I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.