An interesting proposal.
I continue to believe that the largest backers of JPA were against
JDO because of it being binary compatible across object and
relational databases. And due to the "bad blood" between JDO and EJB
2.0. An issue with this approach is that the JPA group could continue
to evolve JPA, making it difficult for the JDO group to produce such
a superset. I have not done a thorough review of JPA, so I cannot
comment on how feasible this is.
Another theory I had was that some of the relational vendors simply
did not want there to be any standard for object persistence. By
introducing JPA, we now have 3 competing APIs: Hibernate, JPA, and
JDO. Most people I talk to these days seem to feel that neither JPA
or JDO has achieved "industry standard status" and people continue to
use and adopt Hibernate because it has the most market adoption.
It is very unfortunate we did not have JPOX for JDO 1.0. That would
have given Hibernate more competition.
I am not advocating Hibernate, I have gotten requests from several
companies recently that have had serious technical issues with
Hibernate, struggling with problems that JDO does not have. But when
I suggest they switch to JDO, they point out that JPA is the
"standard", yet their impression is that no one is using it.
There is lots of confusion out there, most are deciding to not adopt
any technology. Which is what I was concerned was one of the ulterior
motives behind JPA.
On Oct 4, 2006, at 8:52 PM, Ilan Kirsh wrote:
Hi all,
The high traffic in the JDO mailing lists in the last days might
indicate that some implementations may join JPOX soon as JDO 2
compatible. This might be a good time to start a discussion on the
day after JDO 2.0. In my opinion in order to survive as live
technology and not end up like ODMG 3.0 - JDO 3.0 must extend JPA.
I think that as an extension to JPA there is a good chance that JDO
will be able to be attractive again to Java developers, even more
than it was in the good days 2-3 years ago.
By visiting the forums in http://jdocentral.com these days or by
comparing "jdo" to "ejb3", "hibernate java", etc. inhttp://
trends.google.com anyone can see that an urgent action is required
in order to save JDO. We do have some very important assets:
advanced technology, several good quality implementations, happy
users (not as much as we want but still something), the Apache
umbrella, the specification and the TCK, and of course Craig and
all the other wonderful people. Therefore, I believe that an action
now can bring JDO back to business.
Probably most JDO vendors (that have not done so yet) will
implement JPA in the future. But I am not talking on saving vendors
but on saving JDO (even though it could also help the vendors
eventually). Sooner or later these vendors may focus their products
on JPA rather than on JDO that will remain behind. If, however, JDO
3.0 will extend JPA in some way - we might be in a similar position
as Hibernate and Toplink that also support their old API in
addition to the new JPA API, with the advantage that our extensions
are standard and backed by multiple implementations including both
relational databases and object databases (plus some unique
powerful features such as JDO 2.0 fetch groups).
Maybe some JPA issues can be excluded. But in my opinion at least
supporting the new API (e.g. deprecating makePersistent and adding
persist, or supporting both as in java.util.Vector since JDK 1.2)
is a must in order to survive. Maybe some support should even be
added in JDO 2.1. If this direction is accepted - rethinking might
also be required regarding the new support of Java 5.0 based JDO
annotations. I believe that even taking a decision in this
direction and publishing it - may change the momentum for JDO.
Any comments will be welcomed.
Regards,
Ilan Kirsh
ObjectDB Software
http://www.objectdb.com