I have examined the latest version of Castor JDO; it is very different from the Java Data Objects (JDO) standard. It uses Exolab’s OQL query language implementation, which uses ODMG’s query language name, yet it is not compliant with ODMG’s OQL. JDO has its own query facility, called the Java Data Objects Query Language (JDOQL). The JDOQL and OQL languages are very different, offering different capabilities. There are many fundamental differences between Castor JDO and the JDO standard.
I’m a little confused, being an all around blogger and not a java.blogger, with my Java experience being 1.1/1.2/J2SE1.3/1.4. The article alleges that Castor is not JDO (Java Data Objects) compliant. This strikes me as odd, as David Johnson has been using it in a possibly pluggable manner for persistence in Roller. I don’t think it really matters a whole ton, as long as Castor is useful in some way or another, as it appears there are no free (beer, lunch, etc) JDO implementations:
If you are considering the use of the Castor JDO product, you are now aware that it does not support the JDO standard. You would have access to a free object-relational mapping tool, but one with a proprietary API. However, if you would like to build your applications using the JDO standard, you should consider one of the many commercial implementations now available.
So as long as I’m getting my information correctly, horray for Exolab for creating a very cool (free) product, Castor. At the same time, it’d be nice if they made it a little clearer that they were doing their own thing and not implementing the JSR-12 JDO. It confuses the bloggers, for one thing.