O-R mapping tools — a step backward?

First, some history on why I think the Java community missed a step in developing a standard way to use object-relational mapping tools for our data.

When most of us started coding Java, there was JDBC. We saw the API for what it was: a low-level, but standard way we could access databases from different vendors. We could use Oracle, DB2, MySQL, PostgreSQL, etc., and as long as we didn't use vendor-specific JDBC extensions, we could swap out underlying database technologies without having to rewrite out code.

Progress didn't stop with JDBC. It's low-level nature makes coding with it tedious. We have to manage our own transactions, and we have to manage translation between the relational database tables and the business objects we use in our applications.

With EJB 2.0, we got container-managed persistence for our business entities. Vendors provided tools to map relational database tables to EJB entities. The EJB container could be made responsible for reading and writing our Java objects to and from our database tables, freeing us from writing low-level database access code. I think EJB-CMP was the first standard O-R tool in Java.

Today, however, we mostly agree EJBs are too complex for most applications. EJBs have a cost in programmer expertise, project development time, and the cost of hardware and software to run EJB containers.

But if you aren't using EJBs for object-relational mapping, and you want to use a standard object-relational mapping API, what are your choices? The JDO specification came out last year seemingly as the answer. The goal of JDO seems to be to allow a database-neutral O-R mapping system to allow developers to code with objects and worry less about how the objects are stored. And it's supposed to be a standard you knew would be around in the future. A JDBC++.

But JDO seems never to have gained traction. I've never used it on a project, or seen a project with it being used. I'm sure JDO is being used out there. It just doesn't seem to be very common. Did the JDO spec scratch the wrong itch?

Instead of having a JCP standard Java OR-mapping API, we have open-source tools like Hibernate and Cayenne gaining market share as object-relational mapping tools of choice. These tools seem to be answering what developers need. But by using these tools, we're now back to coding to non-standard APIs.

Don't get me wrong. I'm not saying Hibernate or Cayenne are bad. Hibernate is a nice tool. I'm using Hibernate on my current project. And the beauty of tools like Hibernate is I can swap out Oracle and replace it with DB2 and still have most everything work. We haven't gone so far backwards that we're coding to vendor specific APIs. But something still seems wrong here.

Without a standard API, we've gone back to the days of coding to proprietary APIs that could disappear if the open-source developers lose interest. Yes, we still have the source code available (if we remember to download it and store it in our source-code repositories). But five years from now, I bet I could find a Java programmer who understands JDBC faster than I could find a Java programmer who understands Cayenne.

I'm unsure what the next step will be for Java and O-R mapping. Will the Java Community Process adopt a Hibernate-like O-R mapping API to replace JDO? Will JDO eventually capture the mind share of developers? Will the new, "lighter" EJB 3.0 spec provide an O-R mapping API that can be used outside of the EJB container?

Until something like JDBC comes out for O-R mapping, gets widely adopted, and widely accepted by programmers, it seems we're back to the old days of coding to non-standard APIs, locking ourselves into specific technologies. Is this taking a small step backward in order to take a bigger step forward in a few months with a new spec? That's what I'm hoping.