A Short History of JDO

Much of the world's transactional data resides in relational databases. Relational databases model the world using tables of rows and columns. The SQL language is used to manipulate and interrogate the relational model. On the other hand, object-oriented programming languages like Java model the world with graphs of objects. The objects are manipulated in memory by modifying the values of member variables.

Java programs often use relational databases as the datastore, but difficulties and inefficiencies are common. One difficulty is that a fair amount of code must be written to move data from objects to the relational database and back. This code is often repetitious and tied to the relational model. As a result, cut-and-paste errors are introduced. Significant difficulties arise because the application programmer is faced with two models of persistent state, one in the relational model created in the database, and the other in the object model of the application. The programmer must decide whether to implement a full mapping between these two models or only a partial mapping. The first choice is a lot of work, only some of which may be used, while the second choice leads to a patchwork of model synchronization and mapping code that develops as the program design evolves. Whatever he decides, the application programmer must maintain the two models and the code to map between them. The whole business is particularly vexing because application programmers can see that there must be some general-purpose solution that would replace the code they are writing, debugging, and maintaining. Inefficiencies and errors creep in all over the map, but particularly because the typical object-oriented programmer is not proficient in SQL and relational data modeling.

Object databases were created to make it easier and more efficient to manipulate persistent data with object-oriented languages. In the early 1990s, the vendors of object-oriented database management systems were hoping to grow their market by adopting a common interface to object databases. From this desire, the Object Data Management Group was formed. In spite of three revisions of the ODMG specification, it was clear by the late 1990s that object databases were not loosening the grip of relational databases on the world's transactional data.

Although the success of object databases was a disappointment to some, engineers could still see the value of a general-purpose persistence service to handle the mapping between object models and relational databases. Consequently, during the 1990s, object-to-relational mapping tools were created. These O/R mapping tools provided a way for the application programmer to use a packaged general-purpose persistence service, rather than writing his own. Although programming teams have enjoyed good success using these tools, their use is not widespread, and their interfaces remain individual and proprietary.

By the time the Java Specification Request for JDO was adopted by the Java Community Process in June of 1999, the original vision concerning the best way to move data from a datastore to an object-oriented program had narrowed on one end and widened on the other. In terms of object-oriented languages, the vision was narrowed to Java alone. In terms of reaching the datastore, the vision was widened to include relational databases, object databases, and indeed any type of transactional datastore. The basic notion is that Java programmers should have one transactional persistence API, for which the market provides different implementations for different datastores.

As JDO evolved in the expert group, the Enterprise JavaBean specification was adopted by vendors and the development community as the primary model for building and deploying distributed objects on the Java platform. The response in the evolution of JDO was to find the ways that JDO could be used in EJB component development. EJB developers will find that they can use JDO to substitute for the use of JDBC. This substitution might occur in session beans that use JDBC, or it might occur in entity beans where the developer is using JDBC to implement bean-managed persistence.

More than two-and-a-half years after the JDO Java Service Request was submitted, the Java Community Process released JDO 1.0 in March 2002.

JDO 1.0.1

In 2003, the JDO maintenance lead released JDO 1.0.1. The 1.0.1 release offers minor improvements over the 1.0 release. It clarifies some obscurities, resolves some ambiguities and discrepancies, and offers several minor enhancements. When discussing an issue where the 1.0.1 specification differs from the 1.0 specification, this book describes the improvements offered by the 1.0.1 version. When the issue is sufficiently important, this book also draws attention to the differences between the 1.0.1 version and the 1.0 version.