Java Still Struggles With Persistence

By Allen Holub

July 15, 2004 —

When it comes to persistence-storing an object in some place external to your program, ideally in a database-there's a strong need for simplicity.

The Holy Grail of persistence is transparent object storage. I just want to put some object in the persistent store and pull it out again later, as if I were storing the object in a local data structure like a hash table.

I don't want to know anything about databases, XML files or whatever physical storage is used under the covers. Achieving this level of simplicity is very difficult. Sometimes I need to use complex criteria to find a particular object or group of objects, but I want the complexity out of the way when it's not relevant.

You can find proof of the difficulty of building a simple-to-use but powerful persistence system by looking at all the bad implementation floating around.

Roll-your-own systems built on JDBC are too complex, and require specialized knowledge of databases. Object databases looked promising for a while, but they were never trusted enough to be commonly used or sufficiently standardized, and forced you to learn complex new query languages.

I don't want to open the Enterprise JavaBeans can of worms in this column, but unfortunately, many misguided people used EJB to implement persistence-at a huge cost in up-front development time, long-term maintenance problems and runtime performance.

An entity bean is not the same thing as a persistent object. EJB-based O/R-mapping systems such as Thought Inc.'s CocoBase cover the zits with a thin layer of makeup, but they don't solve the problems inherent in the underlying EJB system.

Java's other persistence solutions have also been far from ideal. JDBC doesn't get along very well with the notion of objects, it doesn't provide enough in the way of APIs to let you write in a database-independent way, and at the same time doesn't do many common database-related tasks (like transactions) very well.

The various XML APIs don't talk to relational databases, and introducing an XML-to-database translation layer adds too much inefficiency. Java Data Objects is a step in the right direction, but JDO is way too complicated for my taste, and requires a post-processor that manipulates your bytecode to make an object persistable-something that's bound to cause maintenance problems and also ties your code to a specific vendor.

In the face of all this, I was pleasantly surprised when I looked at the Hibernate persistence framework a few weeks ago (hibernate.bluemars.net).

Currently in release 2.1.3, Hibernate is a mature open-source product that's pretty well conceived and executed. It comes close to achieving my goal of a simple but powerful persistence layer, though some of the flaws of open source are there, too: Hibernate's documentation is marginal, installation is not painless, and so on. You can buy support from JBoss if you need it.

The main strength of Hibernate is its ease of use. Object persistence is accomplished using runtime analysis (via the introspection APIs), so there are no special base classes to extend, no post-processor to run, no hassle. You just open an object that represents the persistent store, and then pass it the object that you want to store.

Hibernate works out of the box with all of the major databases. It even generates the SQL for you if you need it to.

As is the case with all the do-everything-for-you systems, the price you pay for all this power is a less-than-optimal use of the database itself. The system is easily extensible, however. You can get control of virtually every aspect of the database-access process via an XML configuration file or a small number of interfaces that you can implement to customize the system.

You do not have to use machine-generated SQL, or accept the simple field-name-is-the-column-name default. The main issue is that you don't have to do all this stuff, however. The default system works well enough for a prototype (and perhaps for the production application) without any customization.

As a designer, my main complaint about Hibernate is its use of the get/set idiom to tag the fields that need to be stored. Fortunately, Hibernate uses introspection rather than Java interfaces, so you can (and in fact, should) make the getters and setters private; I strongly recommend that you adopt a style guide that requires them to be private.

In general, though it has its warts, I think that Hibernate is the most viable of the Java persistence systems out there, better than all of the more complicated (and often pricey) alternatives.

Allen Holub is an architect, consultant and instructor in C/C++, Java and OO Design. Reach him atwww.holub.com.

Share this link: http://www.sdtimes.com/link/28000

Apache Pivot brings Java into RIA world Open-source Java-based RIA framework brings speed of other RIA development environments to a pure Java world

Java 2009: The language moves to the platform A pair of major acquisitions has potentially diminished Sun's sphere of influence over the language

An opening for closures in Java Sun's Mark Reinhold says he has the answer for Java scaling difficulties, and it involves adding closures to Java

Add comment

Name*
Email*
Country

Comment
Preview

News on Monday
more>>
SharePoint Tech Report
more>>

Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?

Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST