Persistence pays off - Enterprise OSGi in Action - page 56

3.1 Java and persistence

Persistence has been a core part of the Java platform since its introduction. Although
the designers of Java didn't envisage it being used in the kinds of enterprise environ-
ments where it's now common, databases have always been important.

3.1.1 Making persistence easy

One of the aims of the early Java persistence support was to provide solid abstractions
for database access. Databases are notoriously idiosyncratic, and accessing them can
be hard work, so it's an area that benefits from a little help from the platform.

JDBC
Java support for databases began with the Java Database Connectivity ( JDBC ) API , a part
of the core Java platform. All of the classes in the javax.sql and java.sql packages
are part of the JDBC API . JDBC abstracts away the vendor-specific details of connecting
to databases. It also provides interfaces that represent SQL statements and the results
of a query.
Although they're database-independent, these interfaces are thin wrappers for the
raw database access. Developers assume complete responsibility for converting the
result set into Java objects. Developers must also code all of the SQL statements for
inserting and retrieving data. Developers need a fairly solid grasp of SQL and database
administration to achieve much with JDBC . Because SQL support tends to vary
between database vendors, developers also need to know a good deal about the
intended deployment environment for their applications.
This programming model is clearly not ideal, and there have been a number of
attempts over the years to provide more substantial abstractions between the devel-
oper and the database.

ENTITY BEANS
The first attempt to protect developers from databases was the entity bean . Entity beans
were introduced in the Java Enterprise Edition as part of the Enterprise JavaBeans
( EJB ) specification. Entity beans moved to an object-oriented view of database access;
each entity bean represented a collection of data that was persisted. The job of manag-
ing the persistence was handled by the container, leaving the programmer free to
focus on the data structure and the business logic.
It all sounds nice, but after some initial uptake, EJB s were criticized and largely
dropped from any serious business use. There was widespread agreement that the prob-
lem they were trying to solve was a real one, but the entity bean cure might be worse
than JDBC disease. EJB s were heavyweight, difficult to use, and verbose. Developers were
required to implement a dizzying assortment of interfaces and lifecycle methods.
The EJB 3.0 specification has gone some way to rehabilitate EJB s by replacing the
creaking interface-driven beans with annotated Plain Old Java Objects ( POJO s). But
the original entity beans didn't even survive to EJB 3.0, having been replaced with
their more popular competitor, JPA .