Good books or tutorial site for JDO

[jay lai]

Hi,
I am new to JDO, would any one out there recommend me a good reference books or web site that teach you step by step and how JDO works.
REally appreciate your help

[Pradeep bhatt]

Hibernate in action

[pascal betz]

well, since "Hibernate in Action" is about Hibernate (suprise suprise) i dont think it will be on top of your JDO wishlist :-)

check out www.jdocentral.com


cheers

pascal

[Pradeep bhatt]

I am sorry that I refered you to Hibernate book. I thought you were asking for Hibernate book. I will

For JDO you checkout the Orielly book.

[Eric Lemaitre]

Hi !

IMHO it is be totaly worthless to buy a JDO book for a simple glance to this technology (rather download free complete PDF book, check below).
Simply register at IBM and download Paul Monday's JDO tutorial : http://www-106.ibm.com/developerworks/java/edu/j-dw-javajdo-i.html

After this go on LIBeLIS site (best commercial JDO implementation) to "http://www.libelis.com/" and go to "Products", you have a link for "updated docs" and another for "LiDO Community" free version of their product. They have a "samples" directory with many samples, ready to run using ANT.

Please note that I may look to praize LIBeLIS very much, but they succeeded to raise 6 millions euros till then, which is simply by far biggest fund raise for any commercial JDO implementation, so shows a great trust about their future, and no other commercial competitor can match this raise.

Please note too that first JDO book ever edited, Robin Roos' JDO book is freely available as a PDF file (but in no printable version of course) on their site still under "Products" link at "The First book on JDO by Roos Robin" sublink. Sadly you will have to create a login so that their commercials can track you down , but simple checkboxes for refusing periodical offers should leave you free .

Other useful links :
http://access1.sun.com/jdo/
http://www.libelis.com/inner-index.jsp?next=jdo.html#links

Best regards.

[Eric Lemaitre]

Hi !

I forgot to say, stay away for present from Hibernate and Castor-JDO when you think about JDO technology : Hibernate is absolutely not JDO standard compliant right now (they could be and seriously wondering to become compliant, but overwhelming huge work must be done), and Castor-JDO is a valuable ORM tool but has no relationship to JDO standard, their "JDO" stanza was saddly chosen before "JDO" standard existed, hence confusion .

Best regards.

[Peter den Haan]

My understanding is that it's not the amount of work that is holding the Hibernate team back from making the tool JDO-compliant, but dissatisfaction with the JDO standard. And I would discourage anyone from using Castor JDO; contrary to what their respective ages would suggest, Hibernate is more mature by far.

Don't stare yourself blind on standards-compliance. JDO is not an O/R mapping standard. And that's exactly the problem. Well, one of them, anyway.

- Peter

[Eric Lemaitre]

Hi Peter !

My understanding is that it's not the amount of work that is holding the Hibernate team back from making the tool JDO-compliant, but dissatisfaction with the JDO standard.

I didn't want to speak about this point, but there is no dissatisfaction about JDO standard, just huge fights on interests (Oracle's TopLink persistence product is not yet JDO compliant, considering Oracle's strength you can guess JDO has hard time against them), 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.

Don't stare yourself blind on standards-compliance. JDO is not an O/R mapping standard. And that's exactly the problem. Well, one of them, anyway.

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. O/R itself is nothing, most "defineSchemas" vendor tools which can create suitable databases out of Java model are free, BUT the kind of tables made will have a huge impact on performances. So O/R matters much because different mappings will have great impact on performances according to the model.
What is more against your "don't stare yourself blind on standards-compliance", on contrary I stare much because main problems about databases use are the somewhat complicated SQL requests and especially the different SQL brands which vary much (SQL-92 is poorly applied), so 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. Considering complicated database handling inside a project is responsible for one third of total cost, it is excellent to have a standard to make this issue much easier to handle.

Best regards.

[Peter den Haan]

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.

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.

The bit that definitely is untrue is that there is "no dissatisfaction" with the JDO standard. Moreover, that it is the "best persistence standard available" is a pretty weak statement seeing that the only competing standard is EJB 2 Entity Beans. JDO insists on bytecode processing, it will only persist classes, it does not standardise O/R mapping in any way, JDOQL is weak compared to HQL, there's no good detach/attach model, etc. The JDO 2 expert group has acknowledged this from the very start a year ago, so it is a bit strange to see such bald assertions about "no dissatisfaction" here.

If you can live with a proprietary API, you can make a pretty strong case indeed for choosing something other than JDO

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.

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.

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.

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.

- Peter
[ August 29, 2004: Message edited by: Peter den Haan ]

[Eric Lemaitre]

Hi Peter !

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 ?

Because he is an expert about persistence, so he deserved to be there.

Why is the EJB 3 expert group taking such inspiration Hibernate for its persistence needs rather than turning to JDO ?

If you find the real reason, I would like to know it, for there is none sensible. Apparently EJB 3 expert group doesn't like JDO for it can live apart from EJB, while they seem to want a totally dependant embedded persistence model, even to create a new one if needed, while JDO already satisfies ALL EJB needs, is a Sun agreed standard and integrates into EJB without problem. So I don't see AT all why a new standard would be created while JDO already exists and already does as well or better what new EJB persistence standard would do. The fact that JDO can exist without is an advantage, not a drawback, it is excellent to me if EJB assembles other standards which can be used apart if needed, for you learn one technology brick and are not compelled to use it with a mandatory heavy application server elsewhere (do you imagine J2ME application servers with 500Kb to run ? JDO can and EJB cannot, which is no pro/cons because JDO can only persist while EJB can much more than this but needs much more resources).

All is not well in Java persistence, not well at all.

What exactly ? 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.

Politics are definitely a huge part of that. But not the only part.

This is why I wanted to avoid it and remain on pure technical field.

The bit that definitely is untrue is that there is "no dissatisfaction" with the JDO standard.

Yes again, no technical dissatisfaction with the JDO standard, only strong political ones.

Moreover, that it is the "best persistence standard available" is a pretty weak statement seeing the only other standard is EJB 2 Entity Beans. JDO insists on bytecode processing, it will only persist classes, it does not standardise O/R mapping in any way, JDOQL is weak compared to HQL, there's no good detach/attach model. The JDO 2 expert group has acknowledged this from the very start a year ago, so it is a bit strange to see assertions about "no dissatisfaction" here.

_ Why "weak statement" ? Main drawback of EJB-2 Entity Beans is their lack of performance, but JDO can fullfill this need very well, performances with JDO applications inside application servers are better than with their native EJB-2 Entity Beans model, you have many benchs around to prove it.
_ What mean "JDO insists on bytecode processing", "it will only persist classes", in term of advantage or disadvantage ?
_ "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.
_ "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.
_ "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 and I know for sure is implemented at least in LiDO, and must be already implemented by most other vendors too. If you have doubt, download from their site ant try, and read JDO-2 spec for it is there.
_ "so it is a bit strange to see assertions about 'no dissatisfaction' here" is still true on technical field, it is true on political field only so I don't take it into account, for I don't especially mind for example Oracle loosing or not market shares to JDO, I simply care about JDO being the technically best standard persistence system or not, and it is to me.

This is so true that Microsoft has announced the very same persistence model than JDO, but the Dot-Net way of course. They are known to adopt alien technologies (XML for example) only when they are so good they can't be avoided.

[b]If you can live with a proprietary API, you can make a pretty strong case indeed for choosing something other than JDO.[b]

I use ANT and Struts which are proprietary API and I am happy with them, but if I had to choose between standard and no standard technologies for the same purpose, I would choose standard one without hesitation.

Apart from this I am not against Hibernate, I am for standards, Hibernate is good too but right now proprietary so not standard, which is a serious drawback against other persistence standards.

Best regards.

[Peter den Haan]

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.

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.

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.

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.

Yes again, no technical dissatisfaction with the JDO standard, only strong political ones.

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.

Why [is that it is the "best persistence standard available" a] "weak statement"?

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.

What mean "JDO insists on bytecode processing", "it will only persist classes", in term of advantage or disadvantage ?

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.

"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.

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.

"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.

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.

"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

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.

You see? Of course I know it's going to be in JDO 2. That's exactly the point.

[...] if I had to choose between standard and no standard technologies for the same purpose, I would choose standard one without hesitation.

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.

Thanks for a good discussion, Eric. Maybe you think I'm not doing JDO-2 any justice, but it's my own bitter experience that standards-in-progress may change significantly (JSP 2.0, in my case: another story worthy of another thread). For goodness' sake, all that the JSR-243 EG has released so far is an "early draft", you can't seriously start writing production code against that, let alone kid yourself into thinking you're using a persistence standard! You're building your house on quicksand. A proprietary tool would be preferable any time: they will at least make an effort to preserve backward compatibility, but who will care about things that were once in an early JSR-243 draft but which the EG ended up changing their minds about?

- Peter

PS. I wonder if anyone else is still reading this
[ August 30, 2004: Message edited by: Peter den Haan ]

[Eric Lemaitre]

Hi Peter !

PS. I wonder if anyone else is still reading this

Yes, I must sue for peace for this post is turning out as a trench war, We will carry on even longer when we are both retreated .

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.

But JDO is a standard anyway, and JDO-2 is an existing spec we take as reference (I work in this field), and as a simple refinement of previous spec proves its maturity too. There is little which changed between versions 1 & 2, main items were JDO-QL enhancement, OID rationalisation, attach/detach features. Sincerely, version 2 is an enhancement of an already robust and stable technology. It is still young but it is a real need.

For goodness' sake, all that the JSR-243 EG has released so far is an "early draft", you can't seriously start writing production code against that, ...which the EG ended up changing their minds about?

I remain on my position anyway because JDO-2 is no early draft for me, I work with it and it means it is a mature technology (at a JDO's vendor, I must admit it, but if I defended JDO I remained fair). You are still right abount some insufficiances about JDO, for one weakness is Query language. Some sophisticated requests are simply impossible to translate into JDO-QL, direct SQL must be done. So, apart from the necessity to maintain pure SQL requests in case something totally RDBMS specific can be made in SQL only, why not mix JDO-QL and HSQL, nothing against it. JDO-QL strength is to be very near object (classInstance.field = ...), SQL is pure RDBMS oriented, and HSQL could evoluate so as to become an intermediate abstract language somewhere between both, so as to reconciliate both worlds. I am sure JDO-QL will have to evoluate, and in this direction for very pragmatic reasons.

Best regards, and please let's stop there, were are both happy with our respective technologies and don't contempt other concurrents, so let's rest ...