After 15 posts, it is time for this tutorial series to move on from Servlets (and related technologies) in order to cover another part of the Java EE stack - the Java Persistence API, or JPA.
Before we discuss the what and the why of JPA, let’s talk a little about JDBC.
JDBC
If you write Java code for long enough, you’ll find yourself using JDBC sooner or later. And for good reason; it is easy to configure without having to pull down tons of dependencies, and low level enough that you can make it do whatever you want.
That being said, when you find yourself working on a large, database-intensive application, JDBC starts to show its limits. For instance, it would require you to write and manage a ton of hand written SQL statements, and since each database has a slightly different SQL syntax, these statements won’t be portable if you ever switch DB’s.
Additionally, if your database rows are large and complex, you will have to pick through the ResultSet objects returned by JDBC to extract for each column one by one. In short, JDBC is nice to have around, but for certain situations it is more trouble than it is worth.
Object Relational Mapping in JPA
You can look up the finer details of Object Relational Mapping at Wikipedia, but for our purposes, think of it as a way to map your database schema to a Java class. For simple situations, this usually means mapping each column in your schema to a field in the class. Once this mapping is complete, you interact with the DB by creating instances of the class, populating them with data, and calling methods on them to save/update to or retrieve/delete from the DB. Behind the scenes, the JPA library will figure out how to translate these operations into SQL commands to execute.
Things get more complicated when your schema starts to use features like foreign keys, join tables and the like. JPA can accomodate many of these features, but they may require a little bit more effort to get working.
JPA and Hibernate
Hibernate is a Java-based ORM library that existed well before JPA. Along with the Spring Framework, it became very popular for use in Enterprise Java applications. While I don’t have a confirmed source on this, I’ve read claims that JPA only exists because Hibernate became so popular. This claim is supported by the fact that Hibernate’s creator was a member of the committee which helped design the spec.
These days, Hibernate fully implements the JPA spec, and can be used for JPA-based projects. However it also continues to offer its own exclusive features as well. The choice is yours as to whether you wish to use these features in your applications, or whether you wish to stick to the JPA spec for the sake of portability. I bring them up simply so you know that they exist (also, I should note that future code examples will stick strictly to the JPA spec).
JPA Implementations
There are a number of other JPA implementations out there. EclipseLink, for example, happens to be the reference implementation for JPA version 2.0. There is also OpenJPA, TopLink, and DataNucleus. I’ll be using EclipseLink for my examples, but feel free to look around and choose which one you like best.
General Observations
JPA is a great feature, and it can make it tremendously easy to stand up applications which would otherwise be messy and complicated. But it cannot replace the need for knowledge of both SQL and relational databases. Please be familiar with these technologies before using JPA for a serious project.
As you can see, there are a number of different JPA implementations available. This is probably due to the fact that the technology is so useful, and entirely independant of other JavaEE technologies such as Servlets. Whatever the reason, it means that you have a lot of options beyond whatever is offered by JBoss or Apache.