Return to article
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.
The APIs
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.)
Persistence
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
PersistenceManagerFactory.
Castor maintains a single instance of the persistence engine,
SQLEngine. The
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.
The persistence interface
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.
Queries
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.
Mapping
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.
Java-to-XML binding
Sun's JDO doesn't offer Java-to-XML data binding capabilities.
Castor XML provides superior Java-to-XML data binding capabilities.
Unsupported features
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.
Return to article
| 
