|
Home > Archive > Apache JDO Project > October 2006 > The Future of JDO
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Ilan Kirsh 2006-10-05, 1:11 am |
| 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. in http://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
| |
| David Jordan 2006-10-05, 1:11 am |
|
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
>
>
| |
| Andy Jefferson 2006-10-05, 1:11 am |
| > I continue to believe that the largest backers of JPA were against
> JDO because of it being binary compatible across object and
> relational databases.
Agreed.
JPA was "invented" to be so weak that Hibernate and TopLink could be
considered "standards compliant" and to water down any such specification to
allow such RDBMS vendors (you know who they are) to continue to lock clients
in to their bloated RDBMS ... another reason why the JDBC "specification" is
also so weak (and it has had *many* revisions) and doesn't define so many
things (and why the JDBC drivers of aforementioned RDBMS vendors are so poor
at implementing that "specification").
[vbcol=seagreen]
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
| |
| David Jordan 2006-10-05, 7:11 am |
|
One other thing I forgot to mention last night...
Just in the last two weeks there was some discussion among the
members of the local Java User's Group. A few people were complaining
about how difficult and frustrating it was using Hibernate, due to
some of its limitations. They were frustrated there were no
alternatives to Hibernate. JDO does not have the problems that they
were experiencing with Hibernate. So I responded to the discussion
saying JDO did not have those weaknesses of Hibernate, JDO is a
standard, and JDO has a great free reference relational
implementation in JPOX if they needed it to be free.
First, they thought JDO was no longer being worked on, they did not
seem to believe me that the JDO expert group was still actively
refining the standard. They referred to the letter that included the
names of Craig and Linda that Sun published back when we were first
told about JPA. It would help if Craig could publish something that
would indicate that the JDO standard is continuing to evolve. It
would also be good to have statements from implementers discussing
continued adoption of the implementations, so people have written
proof JDO is still alive, evolving, and being used.
Many had never heard of JPOX. There needs to be some articles
published on the Web and in magazines which focus on JDO and JPOX. I
have said this before, marketing of JPOX as the free open source
relational implementation will do more to drive sales of commercial
implementations than anything else. (Andy has not paid me to say
this!) Everyone has heard of Hibernate, but most have not heard of
JPOX. Maybe even an article that does some comparisons of Hibernate,
JDO, and JPA relative to building a small application will drive some
points home.
The fact that JPA has not really had much impact (that is the
perception out there, I don't know the reality, but in the market it
is perception that matters) does give JDO a new opportunity to rise
up and be reconsidered.
On Oct 5, 2006, at 1:08 AM, Andy Jefferson wrote:
>
> Agreed.
>
> JPA was "invented" to be so weak that Hibernate and TopLink could be
> considered "standards compliant" and to water down any such
> specification to
> allow such RDBMS vendors (you know who they are) to continue to
> lock clients
> in to their bloated RDBMS ... another reason why the JDBC
> "specification" is
> also so weak (and it has had *many* revisions) and doesn't define
> so many
> things (and why the JDBC drivers of aforementioned RDBMS vendors
> are so poor
> at implementing that "specification").
>
>
> 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
| |
| Erik Bengtson 2006-10-05, 1:11 pm |
| >
> The fact that JPA has not really had much impact (that is the
> perception out there, I don't know the reality, but in the market it
> is perception that matters) does give JDO a new opportunity to rise
> up and be reconsidered.
>
This is very important point, but maybe optimistic. I would say that's the last
opportunity for JDO to get some traction.
In my packet for JDO 2.1 / 3, I would include services around the API like
failover, transaction recovery, management and monitoring. I dont't see much
things more where JDO could differ from JPA. On the other side JPA has support
from big vendors, and in one way or other this is very confortable for short
term / long term while JDO is perceived as dead by many.
I would love to spend more time on marketing however time is short and market
needs to be followed by execution capacity which, for JPOX at least is limited
by number of contributors.
Regards
| |
| Geoff hendrey 2006-10-05, 1:11 pm |
| Hi All,=0A=0AIt's been a while since I've posted. I've taken down the JDOMa=
x website, and I'm now focusing my efforts on Shades.=0Ahttp://sourceforge.=
net/projects/shadesdb=0A=0AI continue to think that JDO is a leap forward, =
and I continue to share my great experiences as both a user of JDO and an i=
mplementer.=0A=0AUnfortunately, just keeping up with the TCK was becoming a=
goal in and of itself, and eventually I realized one guy simply can't do i=
t. Therefore, I decided to refocus my efforts on smaller core of great idea=
s that came in part from working on JDOMax. I'm hoping that by working clos=
ely with the Wicket community, I can insure that Shades evolves iteratively=
and meets the needs of a focused user base. I'd like to offer up that one =
thing the JDO community could do to drive adoption is insure that JDO imple=
menters work closely with other framework communities, Like Wicket, Tapestr=
y, Webwork, etc. For example, Wicket has a project called "phonebook" which=
is a best practices example for using data access frameworks through Sprin=
g. Ibatis and Hibernate are represented, and I'll add Shades soon.=0A=0Atal=
k soon,=0Ageoff=0A=0A----- Original Message ----=0AFrom: Erik Bengtson <eri=
k@jpox.org>=0ATo: jdo-dev@db.apache.org; JDO Expert Group <jdo-experts-ext@=
sun.com>=0ASent: Thursday, October 5, 2006 5:43:26 AM=0ASubject: Re: The Fu=
ture of JDO=0A=0A>=0A> The fact that JPA has not really had much impact (th=
at is the=0A> perception out there, I don't know the reality, but in the ma=
rket it=0A> is perception that matters) does give JDO a new opportunity to =
rise=0A> up and be reconsidered.=0A>=0A=0AThis is very important point, but=
maybe optimistic. I would say that's the last=0Aopportunity for JDO to get=
some traction.=0A=0AIn my packet for JDO 2.1 / 3, I would include services=
around the API like=0Afailover, transaction recovery, management and monit=
oring. I dont't see much=0Athings more where JDO could differ from JPA. On =
the other side JPA has support=0Afrom big vendors, and in one way or other =
this is very confortable for short=0Aterm / long term while JDO is perceive=
d as dead by many.=0A=0AI would love to spend more time on marketing howeve=
r time is short and market=0Aneeds to be followed by execution capacity whi=
ch, for JPOX at least is limited=0Aby number of contributors.=0A=0ARegards=
=0A=0A=0A
| |
|
|
| Ilan Kirsh 2006-10-05, 7:11 pm |
| 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
| |
| David Jordan 2006-10-05, 7:11 pm |
|
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
>
>
>
| |
| Ilan Kirsh 2006-10-06, 1:12 am |
| 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" <davejrdn@bellsouth.net>
To: "Ilan Kirsh" <kirsh@objectdb.com>
Cc: "Andy Jefferson" <andy@jpox.org>; <jdo-dev@db.apache.org>; "JDO Expert
Group" <jdo-experts-ext@sun.com>
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:
>
>
>
>
>
| |
| Eric Samson 2006-10-06, 1:11 pm |
| 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.=20
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=A0: Ilan Kirsh [mailto:kirsh@objectdb.com]=20
Envoy=E9=A0: vendredi 6 octobre 2006 01:17
=C0=A0: Andy Jefferson; jdo-dev@db.apache.org; JDO Expert Group
Objet=A0: 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=20
> 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=20
> to
> add a new query language but the hook is there. Could be an optional=20
> feature
> in JDO 2.1 ?
>
> 4. Types. Mandate support for Enums, Calendar when running under =
Java5, so=20
> 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=20
> 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.
>
> --=20
> Andy
| |
| Ilan Kirsh 2006-10-06, 1:11 pm |
| 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" <eric.samson@xcalia.com>
To: "Ilan Kirsh" <kirsh@objectdb.com>; "Andy Jefferson" <andy@jpox.org>;
<jdo-dev@db.apache.org>; "JDO Expert Group" <jdo-experts-ext@sun.com>
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:kirsh@objectdb.com]
Envoyé : vendredi 6 octobre 2006 01:17
À : Andy Jefferson; jdo-dev@db.apache.org; 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
| |
| Andy Jefferson 2006-10-06, 1:11 pm |
| > I always introduce JPA as a subset of JDO, which is true in terms of
> concepts
A while back we compiled a table of the differences (between JDO2 and JPA1) to
assist users in choosing what they want. You can find it here :-
http://www.jpox.org/docs/persistence_technology.html
The table is not exhaustive (since we only come to features as we implement
them). For example JPA1 doesn't allow control of specification of
foreign-keys, or indexes whereas JDO2 does - will add this.
I use this table as a basis for defining JPA1 being a subset of JDO2, and as a
basis for defining what JDO2 requires to be a true superset.
If anyone has items to add to that table we'd be happy to update it.
HTH
--
Andy
| |
| David Jordan 2006-10-06, 7:11 pm |
|
But suppose a large percentage of the JPA implementations also =20
provided JDO support...
Suppose all 15 JDO implementations also started supporting JPA, =20
therefore the market would have 15 or so JPA implementations. You =20
probably would not see too many new JPA implementations, new vendors =20
that had not supported JDO. With 15 JPA implementations out there, =20
potential new JPA vendors would decide there were more than enough =20
JPA implementations available, they would not pursue it.
If 90% of those JPA vendors also supported JDO, and JDO had a truly =20
transparent superset API over JPA, then JDO would be positioned quite =20=
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 =20
> its old
> API. A visit in Hibernate forums can also confirm this (compare the =20=
> traffic
> in the main forum to the traffic in the EJB3 forum). However, this =20
> might be
> because JPA is still young and many people are working on existing =20
> systems.
> An happy user do not look for changes. Therefore, the results of =20
> your survey
> also make sense. I also feel that current ObjectDB users are happy =20
> with the
> JDO API and will not switch to anything else.
>
> However, we should try to look what happens in new projects. If I =20
> had to
> start a new project using Hibernate, I would probably be using the =20
> JPA API
> (where possible) to remain unlocked to Hibernate. Many people take =20
> 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 =20
> may be
> 8-10 JPA implementations and then such a decision will be almost a =20
> must.
>
> You write that you see a real value in going in this direction. I =20
> agree that
> the real value is more regarding developers that do not use JDO =20
> today (which
> unfortunately are the majority) rather than regarding the current JDO
> users.
>
> Regards,
>
> Ilan
>
> ----- Original Message ----- From: "Eric Samson" =20
> <eric.samson@xcalia.com>
> To: "Ilan Kirsh" <kirsh@objectdb.com>; "Andy Jefferson" =20
> <andy@jpox.org>;
> <jdo-dev@db.apache.org>; "JDO Expert Group" <jdo-experts-ext@sun.com>
> 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 =20
> 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 =20
> optional in
> JDO (QL).
>
> I agree with David when he says that JPA is not so popular and most =20=
> people
> still use raw proprietary Hibernate.
>
> We recently ran a survey among our users: most of them don't even =20
> require us
> to support JPA, and they won't move to JPA when will support it. =20
> 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:kirsh@objectdb.com]
> Envoy=E9 : vendredi 6 octobre 2006 01:17
> =C0 : Andy Jefferson; jdo-dev@db.apache.org; 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
>
[vbcol=seagreen]
[vbcol=seagreen]
>
>
>
| |
| David Jordan 2006-10-06, 7:11 pm |
|
I think we need several thorough, fair and objective, exhaustive lists:
What does JDO have beyond JPA?
What does JDO lack that is in JPA?
Where are the semantic differences between JDO and JPA and can they
be reconciled?
This list should be used by JDO supporters to decide what should be
done.
This list should also get published.
On Oct 6, 2006, at 11:02 AM, Andy Jefferson wrote:
>
> A while back we compiled a table of the differences (between JDO2
> and JPA1) to
> assist users in choosing what they want. You can find it here :-
> http://www.jpox.org/docs/persistence_technology.html
>
> The table is not exhaustive (since we only come to features as we
> implement
> them). For example JPA1 doesn't allow control of specification of
> foreign-keys, or indexes whereas JDO2 does - will add this.
>
> I use this table as a basis for defining JPA1 being a subset of
> JDO2, and as a
> basis for defining what JDO2 requires to be a true superset.
>
> If anyone has items to add to that table we'd be happy to update it.
>
>
> HTH
> --
> Andy
| |
| Ilan Kirsh 2006-10-07, 1:11 pm |
| Except the number 15 (I am afraid that these days there are much less active
JDO implementations) I agree with every word. Things have changed. The
success of JPA might be now in our interest (anyway more than it is in the
interest of Hibernate...).
----- Original Message -----
From: "David Jordan" <davejrdn@bellsouth.net>
To: "Andy Jefferson" <andy@jpox.org>
Cc: <jdo-dev@db.apache.org>; "JDO Expert Group" <jdo-experts-ext@sun.com>
Sent: Friday, October 06, 2006 11:25 PM
Subject: Re: The Future of JDO
>
> I think we need several thorough, fair and objective, exhaustive lists:
> What does JDO have beyond JPA?
> What does JDO lack that is in JPA?
> Where are the semantic differences between JDO and JPA and can they be
> reconciled?
>
> This list should be used by JDO supporters to decide what should be done.
> This list should also get published.
>
>
> On Oct 6, 2006, at 11:02 AM, Andy Jefferson wrote:
>
>
>
>
>
| |
| Dário Luís Coneglian Oliveros 2006-10-16, 7:11 pm |
| Hi there,
By reading this thread and an article posted by Linda DeMichiel and =
Craig Russell (http://java.sun.com/j2ee/letter/persistence.html), I was =
quite confused about which one (JDO or JPA) to choose as many efforts =
have been pushed towards JSR-220 so far. I know JPA is mainly driven by =
vendors, however I've heard its query language is quite powerful when =
compared to JDOQL.
Any comments would be appreciated.
D=E1rio Oliveros
Software Engineer
CPqD Telecom & IT Solutions
Tel.: +55 19 3705-4586 / Fax: +55 19 3705-6135
oliveros@cpqd.com.br
www.cpqd.com.br
| |
| Andy Jefferson 2006-10-20, 7:11 am |
| > By reading this thread and an article posted by Linda DeMichiel and Craig
> Russell (http://java.sun.com/j2ee/letter/persistence.html), I was quite
> confused about which one (JDO or JPA) to choose as many efforts have been
> pushed towards JSR-220 so far. I know JPA is mainly driven by vendors,
> however I've heard its query language is quite powerful when compared to
> JDOQL. Any comments would be appreciated.
Hi Dario,
A correction. JPA is driven by large corporations and politics. There are
actually many vendors of JDO (the majority with JDO1 solutions, but some with
JDO2 solutions).
I personally would not base any decision on what you hear. Large corporations
say many things and put forward many statements about their preferred
technology based on their own balance sheet and not on capability of the
technology. You should base your decisions on what the specifications
actually say and what implementations do and what you require.
On JPOX we put together a brief comparison of JDO2 and JPA1
http://www.jpox.org/docs/persistence_technology.html
This has been on our site for people to comment/disagree with.
There are other such comparisons around, all coming up with the same basic
opinion. Here are a couple
http://www.jroller.com/page/matthew...arison_of_ejb_3
http://jroller.com/page/ThoughtPark...stand
ard
Any particular feature of JPQL/JDOQL you are referring to ?
--
Andy
| |
| Dário Luís Coneglian Oliveros 2006-10-23, 1:11 pm |
| Hey Andy,
Thanks a lot for the info.
I agree with you that JPA is driven by large corporations and all they =
want is to become standardized in some way.
That's why I want to get a feeling from people working with JDO as I =
find it more complete and robust.
I've been thru JPA specification and found it very tightly coupled with =
relational database, not to mention the use of annotations kind of =
polutes the code.
Regarding your question about JDOQL, I was told that JDOQL would not =
support things like BETWEEN. I don't have much more info about =
particular features, but I will try to find them out and let you know.
BTW, I've been trying to get Teneo EMF and JPOX plugin working, but had =
not luck so far. Has anybody got it working ? I am getting an =
ArrayIndexOutOfBoundsException at =
org.eclipse.emf.teneo.jpox.mapper.GenerateJDO.main(GenerateJDO.java:74) =
when generating the EMF - JDO/JPOX OR mapping. I couldn't find any =
solution on internet.
FYI, I think a must would be having more available tools, such as =
eclipse plugins, in order to get more people using JDO.
Thanks,
D=E1rio
-----Original Message-----
From: Andy Jefferson [mailto:andy@jpox.org]
Sent: sexta-feira, 20 de outubro de 2006 05:26
To: jdo-dev@db.apache.org; D=E1rio Lu=EDs Coneglian Oliveros
Subject: Re: The Future of JDO
> By reading this thread and an article posted by Linda DeMichiel and =
Craig
> Russell (http://java.sun.com/j2ee/letter/persistence.html), I was =
quite
> confused about which one (JDO or JPA) to choose as many efforts have =
been
> pushed towards JSR-220 so far. I know JPA is mainly driven by vendors,
> however I've heard its query language is quite powerful when compared =
to
> JDOQL. Any comments would be appreciated.
Hi Dario,
A correction. JPA is driven by large corporations and politics. There =
are=20
actually many vendors of JDO (the majority with JDO1 solutions, but some =
with=20
JDO2 solutions).
I personally would not base any decision on what you hear. Large =
corporations=20
say many things and put forward many statements about their preferred=20
technology based on their own balance sheet and not on capability of the =
technology. You should base your decisions on what the specifications=20
actually say and what implementations do and what you require.
On JPOX we put together a brief comparison of JDO2 and JPA1
http://www.jpox.org/docs/persistence_technology.html
This has been on our site for people to comment/disagree with.
There are other such comparisons around, all coming up with the same =
basic=20
opinion. Here are a couple
http://www.jroller.com/page/matthew...arison_of_ejb_=
3
http://jroller.com/page/ThoughtPark...e_an_inferior_=
standard
Any particular feature of JPQL/JDOQL you are referring to ?
--=20
Andy
| |
| Marc Prud'hommeaux 2006-10-23, 7:11 pm |
| D=E1rio-
> Regarding your question about JDOQL, I was told that JDOQL would =20
> not support things like BETWEEN. I don't have much more info about =20
> particular features, but I will try to find them out and let you know.
For the record, JDOQL's "someField >=3D x && someField <=3D y" is =20
equivalent to EJBQL/JPQL/SQL's "someField BETWEEN x AND y".
|
|
|
|
|