Castor was initially released in December 1999, before the Sun JSR-000012 Java Data Objects (JDO) specification was released for participant review. The fact that Castor also uses the term Java Data Objects in its name is a coincidence. Castor doesn't implement the Sun JDO specification, nor was that the original creator's intent. The following comparison addresses some of the more important similarities and differences between Sun's JDO specification and Castor JDO. For a more in-depth analysis, see the Resources section.
Sun's JDO provides an API for binding Java objects to enterprise information systems (for example, mainframes, Enterprise Information Systems (EIS), object databases, and relational databases). It also uses the J2EE Connector Architecture to interface with application servers.
Castor provides an API for binding Java objects to relational databases. (While there was an effort at one time to support LDAP stores, it is fairly inactive at present and is in need of a contributor.)
Sun's JDO uses the
PersistenceManagerFactory to create multiple instances of the
PersistenceManager. (An optional feature is the ability to pool the
PersistenceManager interface.) In a managed environment, the
PersistenceManagerFactory is acquired through a JNDI lookup and is used to retrieve
PersistenceManagers. In a non-managed environment, the
PersistenceManager is acquired through a JNDI lookup, by constructing the
PersistenceManager or by way of a
Castor maintains a single instance of the persistence engine,
JDO object is not designed to be pooled because it is constructed using the database name and some other properties and is used to obtain a
Database object. The
Database object represents a connection to the relational database. In a managed environment, the
JDO object is obtained through a JDNI lookup. In a non-managed environment, the
JDO object is obtained through a JNDI lookup or it is constructed.
Sun's JDO requires persistable objects to implement the
PersistenceCapable interface. This interface can be implemented programmatically or by a bytecode enhancer.
Castor doesn't require the implementation of a persistence interface for persistable objects. If you require notification of changes in object state, the
Persistent callback interface is available. You can also enable the
Timestampable interface to assist you in running dirty checks during long transactions in Castor.
In Sun's JDO, queries are achieved through an implementation of the Object Query Language (OQL) that translates OQL into the either the native query language or a specialized API for a hierarchical database or an EIS.
In Castor, queries are achieved through an implementation of the Object Query Language (OQL) that translates OQL into the appropriate SQL.
Sun's JDO uses a Java GUI to create data-object maps, which are then written to a binary file format.
Castor creates data-object maps by hand or by using other tools; the mapping is done using XML.
Sun's JDO doesn't offer Java-to-XML data binding capabilities.
Castor XML provides superior Java-to-XML data binding capabilities.
Sun's JDO doesn't support nested transactions, savepoints, BLOB/CLOB support, read-only fields, or logging.
Castor doesn't support nested transactions or savepoints.