Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Persist data with Java Data Objects, Part 1

Grasp the qualities behind an ideal persistence layer

  • Print
  • Feedback

Page 5 of 6

JDO: Standardized, open, transparent persistence in/for Java

Two standardization/development efforts fall under the name Java Data Objects (JDO): Sun's JDO and Castor JDO.

Sun's JDO

The Java Community Process developed Java Data Objects (JDO), a high-level API specification and a reference implementation. A relatively recent effort, the JDO Java Specification Request (JSR-12) was approved in July 1999 and is a Proposed Final Draft at the time of this publication. In addition to the spec, JDO also includes a reference implementation, although the 1.0 beta version, shipped in second quarter 2001, implements persistence using flat files.

The specification
Sun's JDO specification defines a simple, transparent interface between application objects and transactional data stores. It primarily interests JDO implementation providers. Several vendors have already lined up, but because the specification is a recent development and still in the draft stage, only one or two have implementations out of the beta stage; and not one vendor offers all the features outlined by the specification.

Although Sun's JDO provides data storage-type transparency, the ODMG (Object Data Management Group) 3.0 persistent storage interface and several major ODBMS vendors have heavily influenced the specification. For example, the mapping mechanism format (an XML document type definition) is conspicuously brief, leaving implementation providers to define their own formats -- which limits portability and therefore defies JDO's purpose.

The spec covers:

  • Persistence semantics with respect to transactions
  • Interactions of transactional objects with J2EE
  • Data selection (queries) based on Java expressions


Reference implementation
Sun's JDO includes a functionally limited implementation of the file storage variant and allows storage, retrieval, navigation, and transactional update of persistent instances (no query capabilities).

Third-party implementations
Sun JDO implementation providers fall into two groups:

Nondatabase vendors (independents):

  • SolarMetric Kodo JDO
  • PrismTech OpenFusion JDO
  • TradeCity Cybersoft's Rexip JDO


Major ODBMS vendors:

  • Versant Judo
  • GemStone Systems
  • IBM's Informix
  • Poet Software
  • eXcelon (formerly Object Design)


Castor JDO

An open source project, Castor JDO started in 1999 under the auspices of Exolab. Despite its name, Castor JDO is not compatible with Sun's spec, although it does not differ much. Castor JDO concentrates on relational data stores exclusively, so it does not support data storage-type transparency; however, among the nonproprietary API (open source or multivendor) solutions available, its feature set is certainly among the best, and the price can't be beat. Though the development team seems relatively small, it has been developing Castor JDO longer than Sun has been developing its spec, and it shows. However, as several Sun JDO-compliant solutions quickly mature, Castor JDO's advantage might not last long. Castor JDO meets many of the requirements presented for the ideal persistence layer and therefore deserves a more detailed look.

  • Print
  • Feedback

Resources