But suppose a large percentage of the JPA implementations also
provided JDO support...
Suppose all 15 JDO implementations also started supporting JPA,
therefore the market would have 15 or so JPA implementations. You
probably would not see too many new JPA implementations, new vendors
that had not supported JDO. With 15 JPA implementations out there,
potential new JPA vendors would decide there were more than enough
JPA implementations available, they would not pursue it.
If 90% of those JPA vendors also supported JDO, and JDO had a truly
transparent superset API over JPA, then JDO would be positioned quite
well.... Just a thought...
On Oct 6, 2006, at 11:03 AM, Ilan Kirsh wrote:
Hi Eric,
No doubt that currently most people are using Hibernate and using
its old
API. A visit in Hibernate forums can also confirm this (compare the
traffic
in the main forum to the traffic in the EJB3 forum). However, this
might be
because JPA is still young and many people are working on existing
systems.
An happy user do not look for changes. Therefore, the results of
your survey
also make sense. I also feel that current ObjectDB users are happy
with the
JDO API and will not switch to anything else.
However, we should try to look what happens in new projects. If I
had to
start a new project using Hibernate, I would probably be using the
JPA API
(where possible) to remain unlocked to Hibernate. Many people take
this
exact decision these days. This is today when there are 3 JPA
implementations. I believe that in a short time (1-2 years) there
may be
8-10 JPA implementations and then such a decision will be almost a
must.
You write that you see a real value in going in this direction. I
agree that
the real value is more regarding developers that do not use JDO
today (which
unfortunately are the majority) rather than regarding the current JDO
users.
Regards,
Ilan
----- Original Message ----- From: "Eric Samson"
<[EMAIL PROTECTED]>
To: "Ilan Kirsh" <[EMAIL PROTECTED]>; "Andy Jefferson"
<[EMAIL PROTECTED]>;
<[email protected]>; "JDO Expert Group" <[EMAIL PROTECTED]>
Sent: Friday, October 06, 2006 4:25 PM
Subject: RE: The Future of JDO
Hi all
When I talk to prospects, customers, journalists, etc. I always
introduce
JPA as a subset of JDO, which is true in terms of concepts.
I think there is a real value in aligning JDO on JPA where possible
(annotations, APIs, etc.) or at least in making JPA features as
optional in
JDO (QL).
I agree with David when he says that JPA is not so popular and most
people
still use raw proprietary Hibernate.
We recently ran a survey among our users: most of them don't even
require us
to support JPA, and they won't move to JPA when will support it.
They are
simply happy with JDO and want us to continue to support it.
Best Regards,
....: Eric Samson, Founder & CTO, Xcalia
Service your Data!
-----Message d'origine-----
De : Ilan Kirsh [mailto:[EMAIL PROTECTED]
Envoyé : vendredi 6 octobre 2006 01:17
À : Andy Jefferson; [email protected]; JDO Expert Group
Objet : Re: The Future of JDO
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
