I found now an interesting poll at http://www.java.net/pub/pq/122. The
results should be taken suspiciously of course, but it seems that JDO still
has some hope as it is. However, probably by extending JPA as Hibernate and
TopLink do it has much better chances. I agree that the big question is
whether the effort worth it. I hope it does.
----- Original Message -----
From: "David Jordan" <[EMAIL PROTECTED]>
To: "Ilan Kirsh" <[EMAIL PROTECTED]>
Cc: "Andy Jefferson" <[EMAIL PROTECTED]>; <jdo-dev@db.apache.org>; "JDO Expert
Group" <[EMAIL PROTECTED]>
Sent: Friday, October 06, 2006 1:32 AM
Subject: Re: The Future of JDO
I am not at all opposed to what Andy has suggested. I guess the big
question is whether JDO offers enough beyond JPA that makes this effort
worthwhile, versus everyone just doing JPA.
On Oct 5, 2006, at 7:17 PM, Ilan Kirsh wrote:
My personal feeling after reading the JPA spec and two books on
EJB 3 / JPA is that JPA is not so weak. It has an excellent query
language and API that is very similar to JDO (but more compact).
I highly recommend reading "Pro EJB 3 - Java Persistence API" /
Apress (despite statements such as "as a result JDO spent most of
its time in the persistence underground" and "the writing was on the
wall for JDO" - which are very natural for the two authors that work
for Oracle).
Anyway, I do think that JPA has good chances to succeed. It does
take time to achieve a critical mass of implementations and users but
it seems that JPA is on the right track. If it succeeds we should be
ready. Therefore, I think that Andy's list looks very good as a base
for JDO 2.1.
Ilan
Totally agree. I would think of the following items
1. "persistence.xml". I see no real reason not to allow specification
of
classes to be persisted using persistence.xml as an additional way of
creating the PMF.
2. Persistence API. There are not many differences between JPA and JDO
methods
so what you propose should be straightforward. Those JDO
implementations that
have/are implementing JPA will know that it is simply putting a wrapper
around their existing JDO method. Why not include in 2.1?
3. Query Language. JPQL can be made available via the query "language"
flag in
the existing API (so we add "javax.jdo.query.JPQL" or something as a
valid
value). OK the JDO implementation (if supporting this language) will
have to
add a new query language but the hook is there. Could be an optional
feature
in JDO 2.1 ?
4. Types. Mandate support for Enums, Calendar when running under Java5,
so all
types that JPA supports are there. Why not include in 2.1?
5. Annotations. The donated JDO2 annotations need splitting between
persistence annotations, and ORM. Looking through the JPA annotations
some
time ago, it wasn't clear that we can just take theirs and add others
due to
too many missing concepts. What the JDO(3) spec could do is firstly
define
the precedence of annotations and metadata (to match the JPA spec
definition), and secondly define how JPA annotations can be used by a
JDO3
implementation. In addition provide JDO2/3 annotations to allow finer
definition.
--
Andy
