Chapter 2.
Why JPA?

Java developers who need to store and retrieve persistent data already have
several options available to them: serialization, JDBC, JDO, proprietary
object-relational mapping tools, object databases, and EJB 2 entity beans. Why
introduce yet another persistence framework? The answer to this question is that
with the exception of JDO, each of the aforementioned persistence solutions has
severe limitations. JPA attempts to overcome these limitations, as illustrated
by the table below.

Table 2.1.
Persistence Mechanisms

Supports:

Serialization

JDBC

ORM

ODB

EJB 2

JDO

JPA

Java Objects

Yes

No

Yes

Yes

Yes

Yes

Yes

Advanced OO Concepts

Yes

No

Yes

Yes

No

Yes

Yes

Transactional Integrity

No

Yes

Yes

Yes

Yes

Yes

Yes

Concurrency

No

Yes

Yes

Yes

Yes

Yes

Yes

Large Data Sets

No

Yes

Yes

Yes

Yes

Yes

Yes

Existing Schema

No

Yes

Yes

No

Yes

Yes

Yes

Relational and Non-Relational Stores

No

No

No

No

Yes

Yes

No

Queries

No

Yes

Yes

Yes

Yes

Yes

Yes

Strict Standards / Portability

Yes

No

No

No

Yes

Yes

Yes

Simplicity

Yes

Yes

Yes

Yes

No

Yes

Yes

Serialization is Java's built-in mechanism for transforming
an object graph into a series of bytes, which can then be sent over the network
or stored in a file. Serialization is very easy to use, but it is also very
limited. It must store and retrieve the entire object graph at once, making it
unsuitable for dealing with large amounts of data. It cannot undo changes that
are made to objects if an error occurs while updating information, making it
unsuitable for applications that require strict data integrity. Multiple threads
or programs cannot read and write the same serialized data concurrently without
conflicting with each other. It provides no query capabilities. All these
factors make serialization useless for all but the most trivial persistence
needs.

Many developers use the Java Database Connectivity (JDBC)
APIs to manipulate persistent data in relational databases. JDBC overcomes most
of the shortcomings of serialization: it can handle large amounts of data, has
mechanisms to ensure data integrity, supports concurrent access to information,
and has a sophisticated query language in SQL. Unfortunately, JDBC does not
duplicate serialization's ease of use. The relational paradigm used by JDBC was
not designed for storing objects, and therefore forces you to either abandon
object-oriented programming for the portions of your code that deal with
persistent data, or to find a way of mapping object-oriented concepts like
inheritance to relational databases yourself.

There are many proprietary software products that can perform the mapping
between objects and relational database tables for you. These
object-relational mapping (ORM) frameworks allow you to focus on the
object model and not concern yourself with the mismatch between the
object-oriented and relational paradigms. Unfortunately, each of these product
has its own set of APIs. Your code becomes tied to the proprietary interfaces of
a single vendor. If the vendor raises prices, fails to fix show-stopping bugs,
or falls behind in features, you cannot switch to another product without
rewriting all of your persistence code. This is referred to as vendor lock-in.

Rather than map objects to relational databases, some software companies have
developed a form of database designed specifically to store objects. These
object databases (ODBs) are often much easier to use than
object-relational mapping software. The Object Database Management Group (ODMG)
was formed to create a standard API for accessing object databases; few object
database vendors, however, comply with the ODMG's recommendations. Thus, vendor
lock-in plagues object databases as well. Many companies are also hesitant to
switch from tried-and-true relational systems to the relatively unknown object
database technology. Fewer data-analysis tools are available for object database
systems, and there are vast quantities of data already stored in older
relational databases. For all of these reasons and more, object databases have
not caught on as well as their creators hoped.

The Enterprise Edition of the Java platform introduced entity Enterprise Java
Beans (EJBs). EJB 2.x entities are components that represent persistent
information in a datastore. Like object-relational mapping solutions, EJB 2.x
entities provide an object-oriented view of persistent data. Unlike
object-relational software, however, EJB 2.x entities are not limited to
relational databases; the persistent information they represent may come from an
Enterprise Information System (EIS) or other storage device. Also, EJB 2.x
entities use a strict standard, making them portable across vendors.
Unfortunately, the EJB 2.x standard is somewhat limited in the object-oriented
concepts it can represent. Advanced features like inheritance, polymorphism, and
complex relations are absent. Additionally, EBJ 2.x entities are difficult to
code, and they require heavyweight and often expensive application servers to
run.

The JDO specification uses an API that is strikingly similar to JPA. JDO,
however, supports non-relational databases, a feature that some argue dilutes
the specification.

JPA combines the best features from each of the persistence mechanisms listed
above. Creating entities under JPA is as simple as creating serializable
classes. JPA supports the large data sets, data consistency, concurrent use, and
query capabilities of JDBC. Like object-relational software and object
databases, JPA allows the use of advanced object-oriented concepts such as
inheritance. JPA avoids vendor lock-in by relying on a strict specification like
JDO and EJB 2.x entities. JPA focuses on relational databases. And like JDO, JPA
is extremely easy to use.

Note

OpenJPA typically stores data in relational databases, but can be customized for
use with non-relational datastores as well.

JPA is not ideal for every application. For many applications, though, it
provides an exciting alternative to other persistence mechanisms.