Most of this is not untrue, but too facile. If this were the entire picture, why was Gavin King invited to join the JDO 2 expert group? Why is the EJB 3 expert group taking such inspiration Hibernate for its persistence needs rather than turning to JDO? All is not well in Java persistence, not well at all. Politics are definitely a huge part of that :roll: But not the only part.
Originally posted by Eric Lemaitre:
I didn't want to speak about this point, but there is no dissatisfaction about JDO standard, just huge fights on interests [...] and let's say Hibernate main developer is "very special", considering his technology as the best and despising any other. On pure technical issues JDO is simply the best persistence standard available.
Yes, exactly, and none of that has been standardised, which kinda limits the utility of having a standard in the first place: you're effectively locked into whatever tool you choose. I'm not sure what you're disagreeing with, but I certainly can't disagree with anything you are saying here.
I disagree with you, you are perfectly right on first point but as you stated on your phrase's end, there are other associated problems you cannot ignore [...] So O/R matters much because different mappings will have great impact on performances according to the model.
So will HQL instructions, EJBQL instructions, or for that matter Castor's ODMG OQL instructions. All of these tools will abstract the actual database from you and transparently support a variety of different databases. I don't quite see the relevance of this but again you won't see me disagree: it's GREAT to write *QL and not care about the database.
What is more against your "don't stare yourself blind on standards-compliance", on contrary I stare much because [...] it is GREAT to have a standard about persistence which allows you to learn once JDOQL instructions which will be the same for all databases.
Very true. Maybe the JDO 2 EG won't accommodate EJB 3 needs. Maybe the EJB 3 EG would like persistence to remain locked into the EJB container. Maybe the EJB 3 EG and JDO 2 EG are at war. I'm not sure I want to know. I am sure it's giving Java developers a handicap, and Microsoft an advantage, and we all should be mightily pissed off about that and let them know it.
Originally posted by Eric Lemaitre:
If you find the real reason [why the EJB 3 EG didn't look at JDO], I would like to know it, for there is none sensible.
Which neutral experts? I did follow that little fracas and to my eyes it looked like politics dressed up as a technical discussion from all sides. Not that it was all without technical merits. Gavin did have a number of valid points, as did those refuting him.
What exactly [isn't well at all]? Gavin King made an article strongly against JDO which was estimated as foul by neutral experts for half the reasons were simply untrue and the other gratuitous assesments impossible to check.
Shall we disband the JDO 2 EG then, as they have no work to do? I mean, really, how can you maintain this? I was personally one of those disappointed by the JDO standard when it came out, and while we can have a discussion on how serious the objections against it are, simply stating that there is "no technical dissatisfaction" kills any sensible discussion before it even starts and denies my and many others' opionions any validity. Not very helpful at all.
Yes again, no technical dissatisfaction with the JDO standard, only strong political ones.
Because there are only two Java persistence standards around. When EJB 2 is the only competition in the standards stakes, being the best standard is not saying an awful lot . You don't have to convince me that using JDO in the EJB tier is usually preferable to using entity beans. What I'd rather do is measure JDO against solutions that are not a standard, like Hibernate or, for that matter, Toplink.
Why [is that it is the "best persistence standard available" a] "weak statement"?
Ease of use. The one requires an awkward magic operation for no particularly good reason (as both Hibernate and the current direction of JDO 2 show), the other constrains your object model to concrete inheritance, again unnecessarily.
What mean "JDO insists on bytecode processing", "it will only persist classes", in term of advantage or disadvantage ?
This is not the place for a detailed shootout between JDOQL and HQL, but HQL is definitely more expressive & powerful and I notice that the JDO 2 EG is acknowledging and addressing JDOQL's deficiencies. It's a pity that you accidentally edited away the word that was supposed to sit between "very" and "from SQL"; but to my mind, HQL comes quite naturally to anyone familiar with SQL. Of course you can always drop down to the SQL level in virtually any O/R tool, but doing so completely punctures the abstraction that the O/R mapper gives you: definitely something to be avoided where possible. Much better to have a query language which exposes the full power you have at the SQL level.
"JDOQL is weak compared to HQL" is meaningless, JDOQL is already powerful, can still enhance, and HQL is very from SQL so complicated, and anyway practically all JDO vendors accept queries in full SQL if needed.
With "standardise" I do not mean having just one way to map your classes. That would be silly. What I mean is that JDO does not mandate any configuration or behaviour, expose standardised metadata, or provide any portability requirements that would give you a shred of confidence that your carefully thought out mapping will port from one tool to the other. Again I notice that the JDO 2 EG has acknowledged this as a problem that needs to be addressed in the next version of the spec.
"it does not standardise O/R mapping in any way" is normal, you have 3 usual mappings (Horizontal, Vertical, Filtered), some are more efficient than others according to the situation, so you have to choose your mapping which suits your needs best and it varies. But practically all JDO vendors allow to choose mapping apart default one which is usually Horizontal (One table per concrete class) for most efficient in most cases.
It is not wrong at all. There is no such standard. JSR-243 (JDO 2) is a work in progress, not a standard. I don't doubt that vendors have already started implementing some of its features but any such feature is necessarily provisional. You can use it, but you're no longer using a persistence standard and could just as well (or better, see below) have gone for Hibernate or Toplink or whatever. JDO 2 will change before final.
"there's no good detach/attach model. The JDO 2 expert group has acknowledged this" is totally wrong, detach/attach model exists in JDO-2 standard
Guess what? I completely agree. But the choice is not between a non-standard technology and a standard technology with the same purpose and merit. The choice is between a disappointing and deficient standard (JDO-1), a work-in-progress (JSR-243) which is not standard and is bound to change before it becomes one (JDO-2), and mature and stable tools like Hibernate, or for that matter Toplink, that offer the same ease of use and sophistication without presenting moving targets, thereby combining the benefits of both.
[...] if I had to choose between standard and no standard technologies for the same purpose, I would choose standard one without hesitation.
Look! It's Leonardo da Vinci! And he brought a tiny ad!
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koophttps://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton