I've spent a lot of time keeping tabs on object persistence technology options over the last few years. I've examined, at various times, almost all of the products/technologies mentioned in previous posts. I don't imagine I'm unique in that respect. Here are some thoughts:
- I had no trouble distinguishing Castor JDO and Sun JDO. Anyone seriously considering either technology would discover their non-equivalence in short order. It seems like a mildly unfortunate naming conflict, whatever the reason.
- Different software, even different parts of a single software project, will have diverse requirements and characteristics regarding object persistence. Scaling requirements, transactional behavior, data structure complexity, hardware environment, programming skills, all sorts of other things, will differ, sometimes dramatically, from each other. There is room for many approaches to co-exist.
Saying, for instance, that because Castor uses "slow" reflection, and is therefor less desireable, is making stupid assumptions about the speed requirements of all data persistence problems.
- After reading the JDO spec, and other available JDO material from Sun and others, my feeling is that, while JDO is interesting, and may even become the only sensible option in many situations, it has suffered greatly by clearly being designed in part by a commitee of existing middleware tool vendors, each of whom needs to ensure their existing product's viability.
Designing by committee is a challenging process in the best of situations, adding in the commercial interests of a dozen vendors, many of whom have VERY expensive enterprise relational mapping software packages and corresponding business models, seems like a bad idea. In fact, I'm surprised that JDO turned out as well as it did, and I don't doubt there was a lot of sincere effort put into it- it shows. But the relationship to pre-existing vendor products also shows.
JDOCentral, the "Developers community for Java Data Objects", mentioned in a previous post, also reflects this unfortunate focus on the middleware/tools vendors who participated in the spec-writing. It has a strong smell of "fake-community". It's not all that bad, but it doesn't even bother to hide it's commercial connections, and it's clear use as a marketing tool for those same vendors.
- JDO, like J2EE/EJB, suffers from requiring what often seems like a bit too much of architectural buy-in on the part of developers. Part of this comes from the requirements of playing in the Sun technology sandbox. APIs that make it through the various JCP/JSR wringers tend to not end up as a-la-cart as they might otherwise be.
Sun's desire to avoid angering tools-vendors means that they do a little too much of the "here's a spec, you'll have to pay for a vendor implementation to do anything serious with it". Sure, it's nice to have designs reflect the seperation between interface and implementation, but I'd rather have them come with a basic but serious, solid implementation as a starting point, which is certainly and notoriously not the case with the JDO reference implementation, at least not when I looked at it not too long ago.
- I'm glad that there are as many open-source and low-cost object persistence projects as there are. I don't see a need to create one spec to unify every persistence API out there. Even if one wanted to do such a thing, JDO certainly doesn't succeed.
- I want to suggest an addition to previous posters' mentioned list of persistence APIs. Db4o is an interesting light-weight alternative object persistence framework. I find it interesting because it doesn't map object data to a conventional relational database like most of the other approaches. It, too, has it's quirks, but I wish the JDO team had demonstrated similar willingness to explore designs not based on the assumptions of years of legacy persistence products. it's at db4o.com. I have no relationship with them aside from having tried out their product.
Back to work now, I guess...