Chapter 2. Why JDO?

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

Table 2.1. Persistence Mechanisms

Supports:SerializationJDBCORMODBEJB 2JPAJDO
Java Objects Yes No Yes Yes Yes Yes Yes
Advanced OO Concepts Yes No Yes Yes No Yes Yes
Transactional IntegrityNo Yes Yes Yes Yes Yes Yes
ConcurrencyNo Yes Yes Yes Yes Yes Yes
Large Data SetsNo Yes Yes Yes Yes Yes Yes
Existing SchemaNo Yes Yes No Yes Yes Yes
Relational and Non-Relational Stores NoNoNoNo Yes No Yes
QueriesNo Yes Yes Yes Yes Yes Yes
Strict Standards / Portability Yes NoNoNo Yes Yes Yes
Simplicity Yes Yes Yes Yes No Yes Yes

JDO combines the best features from each of the persistence mechanisms listed above. Creating persistent classes under JDO is as simple as creating serializable classes. JDO supports the large data sets, data consistency, concurrent use, and query capabilities of JDBC. Like object-relational software and object databases, JDO allows the use of advanced object-oriented concepts such as inheritance. JDO avoids vendor lock-in by relying on a strict specification like entity EJBs. Like entities in EJB 2, JDO does not prescribe any specific back-end datastore. JDO implementations might store objects in relational databases, object databases, flat files, or any other persistent storage device. And like JPA, JDO is extremely easy to use.


By default, Kodo stores objects in relational databases using JDBC. It can be customized for use with other datastores.

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


Skip navigation bar   Back to Top