Hi Dave F.
Thanks for your input. I'm glad that the distinction between Castor JDO and JDO (JSR12) was clear to you and presumably to others that are "seriously considering either technology". I wish that everyone making decisions on persistence infrastructure adoption would exert the same due dilligence!
I'd be genuinely interested in the areas you believe JDO suffers because of its "design by committee" origins. Of the vendors who currently market JDO-compliant products I can think of only two who had "pre-existing vendor products" at the time the spec was under consideration. Both of these are ODBMS manufacturers.
On the Object-Relational side all of the companies currently marketing JDO-compliant implementations who were involved in the spec's evolution were created in order to provide JDO implementations, and had no substantial pre-JDO offering in that area. I'm not trying to be facetious here, nor am I guarranteeing that my analysis is correct, but I don't think there was substantial "pre-existing vendor product" bias. Unless you count SQL as one such influence.... Anyway I'd be interested in your (and others) comments.
Of course Sun Microsystems has Forte Transparent Persistence, support for which was dropped as JDO approached specification maturity. I think Forte Transparent Persistence formed a useful technology base from which JDO was grown, rather than Sun exerting any undue influence to steer JDO in its own direction. Once again I might have missed something, I suppose.
As for JDOcentral, it is quite unashamedly sponsored by the JDO vendor community (see the "Steering Committee" page, from "About JDOcentral". Thanks to this financial and directional input, evaluators and users of JDO have a useful forum in which discussions are regularly read and responded-to by experts in the field; some vendor-based and some (like myself) vendor-independent.
Ok, I have a book to promote, so perhaps I'm not as neutral as I claim! At least I disclosed it up-front to this OnJava thread. And whilst it remains the only book dedicated to the topic it can certainly be said to be the best (and, I suppose, the worst!) one....
Now that the spec has been published, Sun's marketing department is faced with quite a dilemma: how should JDO be positioned? Given the recent fuss and expense of EJB 2.0 and CMR, they are understandably careful of JDO's positioning regarding Entity Beans. Currently Sun says "Here is the API" but does not directly advocate its use in any specific architectural tier.
From a JDO-based perspective, the choice to use JDO is reasonably clear in a Client-Server architecture or a Web-based one with no other reason to involve an Enterprise container. I say "reasonably clear" because you have correctly stated that one size does not necessarily fit all as far as persistence infrastructure middleware goes. I will claim JDO is an appropriate choice in "many if not most" of the above scenarios to leave some room for debate.
Once you have an Enterprise container in the architecture, Entity Beans become an alternative. I've tried to highlight some of the pros and cons objectively in a sub-topic to this thread, but my posting has given rise to no subsequent debate, where I had expected substantial debate.
Perhaps that's for another day....
Kind regards, Robin.
Robin M. Roos