Matthew Adams has written up a "Quick Comparison of EJB 3.0 JPA & JDO 2.0," saying that JDO is object-oriented whereas JPA is aimed at relational databases, JDOQL is very "Java-like," and a few other things JDO implemented differently than JPA, like fetching optimizations.

It is my humble opinion that, in the long run, EJB 3.0 JPA will look more and more like JDO 2.0, if not syntactically, at least conceptually. Heck, it already does.

It has to be said that Matthew is a JDO supporter, with other blog entries like "Why do you hate JDO?" (which defends against many of the things people complained about.) JDO still lives, of course. The specification isn't likely to progress much - according to Sun, at least - but JDO remains a good specification, and its users tend to swear by it. However, the majourity of developers seem to have stayed away in droves, and JDO's strengths seem to have not served it as much as it deserved.

JPA targets only relational back ends. JDO 2.0 is still largely datastore type agnostic, but standardizes most things relational.

This is a strength of JDO and certainly possibly a weakness in JPA. However, is this really a problem? How many users are not using a relational datastore? While it's interesting and potentially very useful to be able to map accurately to a heterogenous datastore such as a CODASYL datastore - basically a way of managing data with heterogenous sets, as a drastically oversimplified explanation - how many TSS readers need the capability to do this? So what do - or did - you think of JDO? Many of its ideas found their way into the Java Persistence API; did enough of them? Should the next JPA spec attempt to implement more of the best features of JDO, as Matthew predicts it will?

Having had the need I would say that a standardized way of using various datastores is nice, but I would think that in most cases it's not needed - if you do switch it's between different relational databases. I don't see why JPA shouldn't incorporate it though, if it's to be THE persistence API for Java. Cheers, Fredrik

Having had the need I would say that a standardized way of using various datastores is nice, but I would think that in most cases it's not needed - if you do switch it's between different relational databases. I don't see why JPA shouldn't incorporate it though, if it's to be THE persistence API for Java.

Cheers,
Fredrik

Exactly. 'In most cases it's not needed' is not an excuse for leaving something out. Java has always been about portability and choice. JDO 2.0 shows that you can get first-rate relational support AND the choice of non-relational stores. This has to be the way to go for the future of persistence in Java - just look at the broad choices being offered by competing technologies, such as .NET's LINQ. For Java to close down choices to relational systems would be a backward step.

How many users are not using a relational datastore? While it's interesting and potentially very useful to be able to map accurately to a heterogenous datastore such as a CODASYL datastore - basically a way of managing data with heterogenous sets, as a drastically oversimplified explanation - how many TSS readers need the capability to do this?

If you don't need the 'datastore type agnostic' capability, JDO's major selling proposition, what's the point of using JDO?

How many users are not using a relational datastore? While it's interesting and potentially very useful to be able to map accurately to a heterogenous datastore such as a CODASYL datastore - basically a way of managing data with heterogenous sets, as a drastically oversimplified explanation - how many TSS readers need the capability to do this?

If you don't need the 'datastore type agnostic' capability, JDO's major selling proposition, what's the point of using JDO?

Even if you don't need it for your target backend, try to develop you app with a zero-mapping JDO object database and then move to a RDBMS and see the difference. But there are more. Identity: you don't need an explicit ID field with JDO. If you use an object in a non-persistent context, what does it means that ID field ? JDOQL: it is rather close to Java syntax Field members: no restrictions Fetch groups: fine performance tuning. Guido

How many users are not using a relational datastore? While it's interesting and potentially very useful to be able to map accurately to a heterogenous datastore such as a CODASYL datastore - basically a way of managing data with heterogenous sets, as a drastically oversimplified explanation - how many TSS readers need the capability to do this?

If you don't need the 'datastore type agnostic' capability, JDO's major selling proposition, what's the point of using JDO?

The selling points of JDO - at least for now - are many. (1) There are fewer restrictions on the nature of POJOs with JDO than with JPA - if you use 'final' at all, be prepared to have to re-write things for use with JPA. You also have to include an identity field in your POJOs for JPA but not with JDO. [I would actually question if JPA is truly a POJO approach, as you may often have to either write or modify your persistent objects with JPA in mind - even though you aren't explicitly calling any persistence APIs in those objects, it is not my personal definition of 'Plain Old' Java Objects]. (2) JDO works with pre-1.5 Java versions. This is less and less important, but may still be an issue for some projects. (3) JDO can persist more types of data structure than JPA. For example, in JPA, you are limited to persisting collections and maps of Entities. In JDO you can also persist collections and maps of immutable objects like String, Date, BigDecimal etc. Basically, JDO is less intrusive and more versatile - you can persist a wider range of objects, and can more easily persist legacy objects that have not been coded with the framework in mind, and you can persist to more than relational databases (definitely the way that other frameworks like LINQ are going). I am convinced that JPA will catch up in future versions - and that much of JDO will re-appear on as future enhancements of JPA.

I am convinced that JPA will catch up in future versions - and that much of JDO will re-appear on as future enhancements of JPA.

The fastest way to do it is rename JDO to JPA 2.0 ;)

I am convinced that JPA will catch up in future versions - and that much of JDO will re-appear on as future enhancements of JPA.

The fastest way to do it is rename JDO to JPA 2.0 ;)

Yes, maybe. But there is a problem of "driving forces" that could lead the re-branded JDO to something different. The feeling that I have when I think to these specs is that JDO seems to be driven by developers needs while JPA/EJB3 by vendors needs. Guido.

I am convinced that JPA will catch up in future versions - and that much of JDO will re-appear on as future enhancements of JPA.

The fastest way to do it is rename JDO to JPA 2.0 ;)

Well, actually, if you allow the use of annotations and EJBQL with JDO 2.0, I suspect you may not be far off (or maybe that will be JPA 3.0!)

I am convinced that JPA will catch up in future versions - and that much of JDO will re-appear on as future enhancements of JPA.

The fastest way to do it is rename JDO to JPA 2.0 ;)

Are there features that JPA supports for, say, Hibernate and TopLink that JDO doesn't support (beyond the obvious annotation support)? Could these just as easy have a JDO API as a JPA API?

I am convinced that JPA will catch up in future versions - and that much of JDO will re-appear on as future enhancements of JPA.

The fastest way to do it is rename JDO to JPA 2.0 ;)

Are there features that JPA supports for, say, Hibernate and TopLink that JDO doesn't support (beyond the obvious annotation support)? Could these just as easy have a JDO API as a JPA API?

JDO vendors have found implementing JPA easy because JPA is a subset of JDO 2.0 features (and also of Hibernate features and, I suspect, of TopLink features), so I think the answer is no.

I confirm.

Henrique, Would you please contact me? I want to discuss something with you. andre_aug at brturbo dot com.br

Quoting from the blog entry:

For JPA attachment, you must use EntityManager.merge, but for newly-persistent objects, you must use EntityManager.persist.

This is not correct, please read the definition of merge() in the Java Persistence specification. It works fine with detached or transient instances. I also recommend understanding what merge() does, it does not do reattachment. It's saveOrUpdateCopy() from old Hibernate with a better name and defined semantics. Anyway, my conclusion after having spent a few years with them is that detached objects are not that great. Hibernate users often prefer an extended persistence context, and Java Persistence integrates nicely with stateful session beans to provide this feature.

null/0/false in detached objects are null/0/false because those are guaranteed to be their real values, not just because they were not loaded at detachment time; access to unloaded fields in detached objects throws an exception;

So do proxy-based solutions.

JPA defines an API to manage the locking of a single object. JDO does not define any standard for object locking.

Of course it does, versioning and stronger guarantees with lock() and LockModeType.READ and WRITE. There is more in the blog... but I don't have the time and this thread will create enough ad impressions as it is.

JPA defines an API to manage the locking of a single object. JDO does not define any standard for object locking. Of course it does, versioning and stronger guarantees with lock() and LockModeType.READ and WRITE.

Whoops, my mistake, confusing acronyms.

Quoting from the blog entry:

For JPA attachment, you must use EntityManager.merge, but for newly-persistent objects, you must use EntityManager.persist.

This is not correct, please read the definition of merge() in the Java Persistence specification. It works fine with detached or transient instances. I also recommend understanding what merge() does, it does not do reattachment. It's saveOrUpdateCopy() from old Hibernate with a better name and defined semantics.

Oops, my bad. It was persist() that I should have been pointing out. You are correct about merge(), but persist() is the one that can't handle detached objects. It was for this reason that JDO 2.0 combined its proposed attachCopy() method back into makePersistent(), so that whether you're attaching or persisting anew is immaterial; makePersistent() handles both cases. What's the point of JPA's persist() if you can always use merge() regardless of whether the current persistent state of the object is transient or detached? I did propose the same thing in JPA (getting rid of merge() and just using persist()), but I think it was too late in the process.

Anyway, my conclusion after having spent a few years with them is that detached objects are not that great. Hibernate users often prefer an extended persistence context, and Java Persistence integrates nicely with stateful session beans to provide this feature.

Again, JDO supports the same concept, as I mentioned in the blog.

Should the next JPA spec attempt to implement more of the best features of JDO, as Matthew predicts it will?

First of all, why create JPA if JDO is already there? .. And unlike JPA, it's not under specified. We will see a lot of JPA impls with huge behavior differences, but unless you change the implementation it should not be a problem.

First of all, why create JPA if JDO is already there?

Now that is a question that opens many political and technical cans of worms......

First of all, why create JPA if JDO is already there?

Now that is a question that opens many political and technical cans of worms......

And what's the problem in doing that ? It could be done without religion/flame war, I think. What I see is a constant attempt to make the community forget about JDO existence, even from old JDO vendors. It looks like JDO being perceived as a danger for EJB3 evolution (IMHO complete survival) and so it MUST be suppressed. This is not exactly what is called fair competition. Guido

First of all, why create JPA if JDO is already there?

Now that is a question that opens many political and technical cans of worms......

And what's the problem in doing that ?
It could be done without religion/flame war, I think.

I doubt it :)

What I see is a constant attempt to make the community
forget about JDO existence, even from old JDO vendors.
It looks like JDO being perceived as a danger for EJB3
evolution (IMHO complete survival) and so it MUST be suppressed.
This is not exactly what is called fair competition.

Guido

I agree that there are attempts to try to make JDO a forgotten JSR, but I doubt it will work. JDO has certainly not had mass use, but there are (in my view) sufficient users that it is nowhere near dead, and will be around for some time. What I think will be interesting is the iminent release of products (such as Kodo) that implement both JDO 2.0 and JPA at the same time - even allowing their simulaneous use on the same objects in the same application. This could lead to a number of users who pick up on BEA Kodo (for example) for use as a JPA implemenation, and who then discover the additional features of JDO. I think there may be continuing questions about why the 'Persistence Architecture' for Java (JPA) is so under-specified compared to JDO 2.0. Hopefully this will lead to continued pressure for a better JPA 2.0. I am perfectly prepared to switch to JPA in future, but only if it means I don't have to step backwards in terms of ease-of-use and capabilities compared to JDO. This would certainly be the case now.

I agree that there are attempts to try to make JDO a forgotten JSR, but I doubt it will work.

It will not. It would rather gain a "cult status" among the developers who are ready to venture beyond Employee-Department domain models with their O-R mapping tools.
This could lead to a number of users who pick up on BEA Kodo (for example) for use as a JPA implemenation, and who then discover the additional features of JDO. JDO can always gain from sponshorship of a reputed and established vendor. Hope your prediction comes true.

Who cares? JDO is dead. We finally have a POJO persistence model that is integrated with Java EE. Let's move on and look forward instead of looking back. Bill Redhat Inc.

Who cares? JDO is dead. We finally have a POJO persistence model that is integrated with Java EE. Let's move on and look forward instead of looking back.

Bill
Redhat Inc.

Wether or not you think JDO is dead, this is about looking forward. It is about how we can improve JPA by considering what many of us believe is good about JDO. What some of us are after is a specification which looks forward to new approaches and does not limit our choices. JPA is not that specification (yet).

Who cares? JDO is dead. We finally have a POJO persistence model that is integrated with Java EE. Let's move on and look forward instead of looking back.

Bill
Redhat Inc.

Hurra !!! It reminds me something related the congratulations sent to MS from Apple when they broke the 8.3 filename limit. You finally arrived where we were at least 3 years ago. Anyway, why persistence should be tied/related to Java EE ? Don't you think that persistence standardization could be useful in plain J2SE apps too ? Obviously in this last case no $$ for containers vendors. Guido

Who cares? JDO is dead. We finally have a POJO persistence model that is integrated with Java EE. Let's move on and look forward instead of looking back.

Bill
Redhat Inc.

JPA is a looking back to EJB 2. If we keep looking JPA forward we see JDO 2. Sadly, people keep self-liying to avoid facing desolution for what they call JPA

Who cares? JDO is dead. We finally have a POJO persistence model that is integrated with Java EE. Let's move on and look forward instead of looking back.

Bill
Redhat Inc.

COOL! This is going to be great ..... Already 3 replies within 40 minutes. PJ Murray, CodeFutures Software Data Access Objects and Service Data Objects

Who cares? Persistence is dead. We finally have a no-value POJO persistence model that is integrated with the dying Java EE. Let's ignore developers' interest and look forward to nowhere instead of still believing in true values. Finally Hibernate and Toplink have their own spec. They are not "proprietary" any longer. Keep cool Bill. You won. Exactly like Darth Vador in Star Wars IV :-) It was too difficult to reach the Jedi (JDO) standards. Bill: we're still stuck in a holy war. Have a breath. Take a break. We now all have to continue to work together on Java persistence: JPA 1.0 was just a first step in the very long persistence trek.

It is no longer possible to tell whether Hibernate's huge popularity was generated by the slogan "Hibernate is EJB3", or the other way around, i.e. JPA's creation (and JDO's final underdog status) was caused by the popularity of Hibernate.

"JDO's final underdog status" should be corrected to "JDO's current underdog status". Final? who knows?

Who cares? JDO is dead.

Why such elation about perceived death of JDO, which if not anything, is another professional grade approach to transactional object persistence?

We finally have a POJO persistence model that is integrated with Java EE.

...which is greatly influenced by JDO to rectify the great earlier misadventure known as EJB 1.0 and 2.0 (for those low on history).

JDO was perceived as a danger for big Database vendors Why? Once you start using a database you usually learn some proprietary SQL, Store procedures , etc. When you allow your programmers writing proprietary sql sentences they become zombies defenders of the database vendor because they simply feel comfortable with what they have learnt. It is very difficult to change a project's database if you don't have a strict specification for the transparent persistence. JDO is really agnostic and you don't need to code for the Database. There was no need for EJB 3.0 JPA, it was just a divide and conquer strategy to maintain Database vendors Status Quo.

JDO was perceived as a danger for big Database vendors
Why?
There was no need for EJB 3.0 JPA, it was just a divide and conquer strategy to maintain Database vendors Status Quo.

Not strangelly that JPQL inherits relational database vendors limitations. As many databases, JPAQL requires "fields" in "order by" clause to be projected too (in select clause). This is clear due to some relational database limitations.

...the majourity of developers seem to have stayed away in droves, and JDO's strengths seem to have not served it as much as it deserved.

I'd say that developers haven't actively "stayed away" so much as not tried it out, and given the past, I'm not surprised. It's almost comical all that JDO has had to overcome over the years: * The whole "Castor JDO is not Sun JDO" thing * The now-defunct fear of bytecode weaving * The fact that JDO is in JEE by being a JSE spec instead of a JEE spec * The false assertion that it's a specification for object-oriented databases * TSS's infamous thread 771 * JDO 2.0's welcoming of other persistence solutions and their subsequent desertion * The "string-based query vs. SODA vs. criteria-based query" argument * The fact that JDOQL is not SQL, even though JDO 2.0 standardizes SQL, real SQL, too * The original lack of a quality open source implementation I wouldn't say that developers have stayed away as much as they have taken the word of others more than they should have. JDO 2.0, as you imply, deserves more widespread recognition based on its merits. If only folks would look at it from a technical perspective, I think they'd see that it's not only a great specification, but that it imparts incredible freedom to developers that want to use objects to the fullest extent among all of the current and past specifications.

JDO MUST follow its own route. It was a superior specification years before the Hibernate hype, today it continues being superior to JPA. While people were fighting against EJB<=2.0 problems and Hibernate didn't exist, JDO customers were building complex object models in a breeze. JDO is the dream of object databases using RDBMSs, why to kill it? JPA is a very huge step forward but again the object model continues with database dependencies like the ID field. Does an "in memory" Java object need an ID? The object identity is managed by the JVM, the persistent transparent mantra was ever "the database is like the memory", in the ObjectStore days we had a C++ "new" persistent, today is not so transparent but it is basically the same with JDO. JPA is ok but JDO was ever been more ambitious, the technology cannot stop by “political� reasons (Hibernate was a winner example about this). Jose M. Arranz JNIEasy: Java Native Objects and yes JNIEasy was inspired by JDO in another camp.

Hi there, I don't have a deep, if any, knowledge about the differences between JPA and JDO. This thread gave me a very raw idea, so thanks all for this! Jose wrote :

[...]
JDO is the dream of object databases using RDBMSs, why to kill it? JPA is a very huge step forward but again the object model continues with database dependencies like the ID field. Does an "in memory" Java object need an ID? The object identity is managed by the JVM, the persistent transparent mantra was ever "the database is like the memory", [...]

I just have a little question : if you have several JVMs sharing the same 'persistent' object, can you still live without an ID? -- Julien.

if you have several JVMs sharing the same 'persistent' object, can you still live without an ID?

Yes, JDO manages it for you

if you have several JVMs sharing the same 'persistent' object, can you still live without an ID?

Yes, JDO manages it for you

The biggest obstacle for jdk2 is, no opensource implementations as yet, no affordable tooling (with affordable I mean suited for a mass adoption not corporate adoption) JPA has somewhat 3 opensource implementations by now, one by a JDO vendor, it has tooling in Eclipse and Netbeans and both can be gotten for free if you need only the basic stuff, like round tripping db reverse engineering. So where is JDO2, a bunch of commercial companies, expensive tooling, expensive libraries (although that might change over time) One of the reasons why Hibernate took over was, that it was free, while the rest either sucked or in case of jdo cost a fortune!

So where is JDO2, a bunch of commercial companies, expensive tooling, expensive libraries (although that might change over time)
One of the reasons why Hibernate took over was, that it was free, while the rest either sucked or in case of jdo cost a fortune!

Ok I have to write my own rebuttal, as it seems there is jpox as opensource jdo2 implementation. Sorry about this misinformation. The Tools aspect unfortunately still is there. I will give jdo2 in the future now that I know there is something along the budget I can afford, a second look.

So where is JDO2, a bunch of commercial companies, expensive tooling, expensive libraries (although that might change over time)
One of the reasons why Hibernate took over was, that it was free, while the rest either sucked or in case of jdo cost a fortune!

Ok I have to write my own rebuttal, as it seems there is jpox as opensource jdo2 implementation. Sorry about this misinformation.
The Tools aspect unfortunately still is there.
I will give jdo2 in the future now that I know there is something along the budget I can afford, a second look.

For what concerns the costs, this is a relative subject and I have considered expensive just 1 JDO product among 5-6 I have checked. Don't you think that EJB3/JPA is a bunch of commercial companies too ? BEA, Oracle, IBM are non-profit organizations ? FYI, here a short list of opensource JDO implementation: JPOX (since JDO1) speedo (since JDO1) JDOInstruments (rather recent but not JDO2 compliant) OpenAccess (was JDOGenie, then Versant OpenAccess, now a fork from last release - 4.0.2 - from Versant is on sourceforge, while another fork is managed by Vanatec) Not considering (non opensource) free version (for restricted use): ObjectDB XCalia More, AFAIK, no runtime fee is requested for all the commercial products available (with the exception of the expensive one). No, I don't think that costs is a problem for JDO adoption. Guido

JPA has somewhat 3 opensource implementations by now, one by a JDO vendor, it has tooling in Eclipse and Netbeans and both can be gotten for free if you need only the basic stuff, like round tripping db reverse engineering

One is Hibernate. Another is Kodo, that is (maybe was) primarly a JDO implementation with an Eclipse plugin. Then TopLink, that, I think, is the RI for JPA. I remember some statements from Oracle on JDO when they acquired TopLink, but maybe they considered much more interesting jump (or stay) on EJB bandwagon. Hibernate was born opensource, while the other two, IMO, have become opensource for necessity. Stop. You can find more comments on this subject searching my posts on TheServerSide. Guido P.S. Is there any commercial JPA implementation ? No ? Strange, why ?

JPA has somewhat 3 opensource implementations by now, one by a JDO vendor, it has tooling in Eclipse and Netbeans and both can be gotten for free if you need only the basic stuff, like round tripping db reverse engineering

One is Hibernate.
Another is Kodo, that is (maybe was) primarly a JDO implementation with an Eclipse plugin.
Then TopLink, that, I think, is the RI for JPA. I remember some statements from Oracle on JDO when they acquired TopLink, but maybe they considered much more interesting jump (or stay) on EJB bandwagon.
Hibernate was born opensource, while the other two, IMO, have become opensource for necessity. Stop.
You can find more comments on this subject searching my posts on TheServerSide.

Guido

P.S.
Is there any commercial JPA implementation ?
No ? Strange, why ?

ahem hibernate is not jdo it is its own api with a thin jpa layer, kodo is not opensource, only the core openjpa codebase, the same goes for toplink where only toplink essentials is oss and that one is jpa only as well. (besides that correct me if i am wrong I am not too familiar with toplink, but it is not jdo either ;-) )

As for commercial jpa implementations, sorry to add another post, I missed somewhat the original content of the quoting, so my reply was somewhat out of scope. You can count kodo and toplink into the category, because both products add another api layer which then can be mixed into jpa. I rather doubt we will see jpa only commercial implementations, due to the fact alone that Hibernate and the JPA RI are oss. But most orm vendors already showcase products which also integrated jpa as one of the core apis. So the future of jpa is, as standard api in every JEE5 server, as core api for Hibernate and as somewhat unifed second core api in other orm layers, like JDO.

JPA has somewhat 3 opensource implementations by now, one by a JDO vendor, it has tooling in Eclipse and Netbeans and both can be gotten for free if you need only the basic stuff, like round tripping db reverse engineering

One is Hibernate.
Another is Kodo, that is (maybe was) primarly a JDO implementation with an Eclipse plugin.
Then TopLink, that, I think, is the RI for JPA. I remember some statements from Oracle on JDO when they acquired TopLink, but maybe they considered much more interesting jump (or stay) on EJB bandwagon.
Hibernate was born opensource, while the other two, IMO, have become opensource for necessity. Stop.
You can find more comments on this subject searching my posts on TheServerSide.

Guido

P.S.
Is there any commercial JPA implementation ?
No ? Strange, why ?

ahem hibernate is not jdo it is its own api with a thin jpa layer, kodo is not opensource, only the core openjpa codebase, the same goes for toplink where only toplink essentials is oss and that one is jpa only as well.
(besides that correct me if i am wrong I am not too familiar with toplink, but it is not jdo either ;-) )

Either you missed my point or I completely misunderstood your reply :) I have read in your post a certain advantage of JPA over JDO because of 3 OS impl in contrast with none of JDO. What I intended to reply is that of these 3, the only original OS is Hibernate. The other 2 have, IMO, a different story. AFAIK, Kodo will be opensource for the JPA part and the core runtime. The JDO part will not (do you see any link with "strange" in my previous post ?) I mean, some popular non-profit organizations (BEA, Oracle) are pushing JPA in any way. Again, it is not a fair competition. Guido

Some big companies make a hype about JPA and claim already for years that JDO was dead. But is JDO really dead? No! The opposite is true: After JDO 2.0, the new versions 2.1 and 2.2 were released and 3.0 is currently in the final draft phase. The specification is permanently developed and far from dead. JDO is a powerful, mature spec and I really love using it.

Now compare this to JPA 2.0, which still lacks heaps of features compared to JDO. If you ever used JDO and come now to help in a project that uses JPA, you're only puzzled about how incomplete, user-unfriendly and immature JPA really is.

Here a short list of things that really frustrate me:

• JPA has no fetch groups.
• There's nothing like JDOHelper.getObjectId(Object).
• Detached objects not portable.
• The available callback/lifecycle events are incomplete.
• JPQL is an extremely ugly language (more SQL-like than Java-like).
• There is no Generics support when used with Hibernate 3.5.x.

I don't want to repeat myself here and thus kindly ask you to look at the details on Why not JPA on jfire.org. Btw. it's very likely that this list is going to be extended as we stumble over flaws and constraints in JPA again and again.

Best regards, Marco :-)