JDOCentral has made available an online petition for the community to sign and show the JCP EC their support for JDO, citing reasons including the success of JDO so far, the need for O/R standards today, JCP bias towards EJB 3, and the possibility that a NO vote would cause JDO to be developed outside of the JCP. A successful petition would demonstrate community interest in continueing JDO, and as of Friday, Feb 4th, 665 people have already signed.

The online petition to the Java Community Process Executive Committee be signed here:
http://jdocentral.com/JDO_SignOurPetition_Form.html

According to Dirk Bartels, General Manager of JDOCentral:

The acceptance of the Java Community Process’ (JCP) JSR 243, also known as JDO 2.0, is in jeopardy. The recent vote by the JCP Executive Committee in the so called Public Review Ballot resulted in 5 YES votes and 10 NO votes and 1 abstention. In response to these results, we have prepared an online petition addressed to the JCP Executive Committee. Please support JDO and help us in our efforts to lobby for the adoption of the JDO 2.0 standard. You should have the right to choose whether or not the JDO 2.0 API is available and "standard" for your use. Some of the leading members of the EJB community who sit on the JCP Executive Committee want to take that right away from you.

You can read the rest of Dirk's plea here:
http://jdocentral.com/JDO_Commentary_DirkBartels_4.html

Previous discussion threads on TSS:
JDO 2.0 Public Review Ballot votes NO.
JDO Expert Robin Roos calls for Faith in the JCP.

Whilst I welcome the JDOCentral initiative, it is much more beneficial for individual JDO users to write to the JCP executive committee about their company's positive experience of and committment to JDO. Up until now a lot of people have been duped into believing that there is no JDO community. Thanks to the many emails received by the JCP Executive Committee members since the vote on JDO 2.0's Public Draft it is now known that JDO plays a significant part in the Java community.

If an Executive Committee member receives 10 emails with identical content, and different "signatures", this is much less impressive than 10 individual emails written by individuals stressing the importance of JDO.

So go ahead, sign the petition at JDOCentral, but write to the Executive in your own words as well. All of their emails addresses are available c/o the JCP website.

Kind regards, Robin.

***Editors Note*** The JCP emails are here:
http://www.jcp.org/en/participation/committee#SEEE

Whilst I welcome the JDOCentral initiative, it is much more beneficial for individual JDO users to write to hte JCP executive committee about their company's positive experience of and committment to JDO.

I would encourage NON supporters send emails as well because if only JDO proponent will it might create wrong picture. Better yet to setup public poll for developers where everybody will be able to vote.

I would encourage NON supporters send emails as well because if only JDO proponent will it might create wrong picture. Better yet to setup public poll for developers where everybody will be able to vote.

Could you please help me understand how the acceptance of the JDO 2 spec would put you (or anyone else not using JDO) at a disadvantage?

Thank you,
Oliver

Could you please help me understand how the acceptance of the JDO 2 spec would put you (or anyone else not using JDO) at a disadvantage?Thank you,Oliver

I consider JDO harmful because it makes nonsensical claim of storage agnosticism and therefore encourages ignorant and uninformed designs by less than perfect designers. That harms the rest.

Now apparently there is a market for JDO and users have been requesting extensions to the original specifications.

Considering that you will not be forced to use JDO, what would you gain from denying those users what they asked for?
(I might have a problem with your favourite piece of technology, but I do not see what I could possibly gain from denying you the use of it.)

Or, asking again as you did not really answer the question, how would the mere acceptance of the JDO 2 spec harm you directly as a non-user?

Cheers,
Oliver

how would the mere acceptance of the JDO 2 spec harm you directly as a non-user?

It will!!! It will put more pressure on the big guys implementing the EJB 3 spec to produce a no-nonsense spec and implementations that actually work and are productive. (which they won't like)

It will also give users a choice of defecting to productive implementations of JDO. And, the big guys will lose their monopoly.

This is more of a business game than a technical one.

...This is more of a business game than a technical one.

Now we are talking sense.

For vendors, one requires an EJB container and the other one doesn't.

Which one do you think they'll be motivated to work with?

ie

http://www.hibernate.org/247.html

ie http://www.hibernate.org/247.html

Exactly... In fact, features of EJB CMP today (2.x) are quite visable in POJO persistence layers. POJO support for EJBQL, relationship maintenance, etc... Fact is, supporting J2EE and J2SE persistence under the EJB3.0 is both technically and from a business perspective absolutely trivial. The proof is right there.

 - Don

Fact is, supporting J2EE and J2SE persistence under the EJB3.0 is both technically and from a business perspective absolutely trivial. The proof is right there. - Don

This never was a technical issue - the problem is that it is likely that for using the EJB3 persistence API, you will have to use an application server (after all thats a big market we're talking about here). Which is just plain silly if you don't develop a J2EE app. Rather it should be the other way around, POJO persistence should be a simple J2SE API which EJB3 uses (and perhaps extends, e.g. CMT). And this is why the JDO folks don't understand (on a technical, objective level) why EJB3 does not use JDO2 as its persistence layer when JDO2 does supply this simple J2SE API.

ie http://www.hibernate.org/247.html

Exactly... In fact, features of EJB CMP today (2.x) are quite visable in POJO persistence layers. POJO support for EJBQL, relationship maintenance, etc... Fact is, supporting J2EE and J2SE persistence under the EJB3.0 is both technically and from a business perspective absolutely trivial. The proof is right there. - Don

Don

While I am unsure of what exactly you are trying to say above, the bit about CMP 2.x features being usable in POJO persistence layers seems self-evident to me. This is especially so when considering the fact that at least one CMP implementations is built on a JDO implementation.

And before anyone feels the need to point this out to me, I am quite happy to accept that CMP 2.x can be implemented on top of e.g. Hibernate or possibly--if you really must--even TopLink. After all, CMP 2.x is a small subset of what users would expect from a decent Java persistence solution.


Kind regards,

Oliver

ie http://www.hibernate.org/247.html

What is the point ? That you can use EJB3 annotations with Hibernate ? Besides the fact that the EJB3 spec is far from finished, there is a lot more to a persistence api than how to define what objects are persistent and in what way (which in this case is not even POJO).

ie http://www.hibernate.org/247.html

What is the point ? That you can use EJB3 annotations with Hibernate ? Besides the fact that the EJB3 spec is far from finished, there is a lot more to a persistence api than how to define what objects are persistent and in what way (which in this case is not even POJO).

I was wondering about the relevance of the link myself, but I think the bottom line still is this: the JSR-220 expert group as well as Sun have publicly stated their intention that the persistence mechanism developed through JSR-220 will be usable in J2SE environments.

At this time I do not see any reason to question this, although of course there are no details on what exactly this support will look like yet.

ie http://www.hibernate.org/247.html

What is the point ? That you can use EJB3 annotations with Hibernate ? Besides the fact that the EJB3 spec is far from finished, there is a lot more to a persistence api than how to define what objects are persistent and in what way (which in this case is not even POJO).

Hibernate3 core has evolved to handle the EJB3 persistence semantic described in the spec. Hibernate Annotations binds EJB3 annotations to Hibernate3 core and the whole provides an implementation of the EJB3 persistence part.

Or, asking again as you did not really answer the question, how would the mere acceptance of the JDO 2 spec harm you directly as a non-user?Cheers,Oliver

I will try rephrase since I did not make myself clear enough: JDO2 as standards will harm me in the same way as SOAP harms me.

If SOAP does not harm YOU it is OK with me. You do not have to understand why JDO hurts me- it is fine. I just want all voices being heard and counted.

You still haven't explained why JDO hurts you? Simply saying that it does is not an explanation. I can't see how other developers been given access to a tool can hurt you. Sure they might not use it correctly and produce a bad application, but that argument can be made for sooo many other technologies as well it just doesn't hold water with me.

Rob

You still haven't explained why JDO hurts you? Simply saying that it does is not an explanation.

I tried. Please simply accept that some explanations does not make sense for everybody, it is OK.

I can't see how other developers been given access to a tool can hurt you. Sure they might not use it correctly and produce a bad application, but that argument can be made for sooo many other technologies as well it just doesn't hold water with me. Rob

Could you explain how opposition to nonsense spec prevents users from having access to JDO2 or whatever set of features: implemented but not standardized?

Why do you want to shut up opposition to JDO? Let people decide, please.

The problem here is not that other developers using JDO could hurt anybody. The problem is that companies with the big bucks deviating some of the little effort that can be put into R&D nowadays from EJB, which I like, to JDO, which I consider inferior, will mean a poorer EJB specifications and implementations in short-to-mid term.

Did you notice who voted yes and who voted no? It appears, as someone has already pointed out, that it is a market issue, not a technical one. Borland voted yes, which is remarkable. And JBoss Inc. voted no, unlike Apache. Which can lead to malicious thoughts...

The problem here is not that other developers using JDO could hurt anybody. The problem is that companies with the big bucks deviating some of the little effort that can be put into R&D nowadays from EJB, which I like, to JDO, which I consider inferior, will mean a poorer EJB specifications and implementations in short-to-mid term.

JDO is not part of J2EE, and so appserver vendors are not forced to implement JDO. Evolving the JDO specification has no negative effect on EJB. It does, however, have a very positive effect for current JDO users and any other developers whose needs are not met by the EJB specification, or who cannot wait for that specification and its implementations to mature. The POKP persistence experience that both developers and implementors gain through JDO will also benefit the EJB spec.

p.s. If you think JDO is inferior to EJB 3 for technical reasons, please send your thoughts on the shortcomings of JDO to:
jsr-243-comments at jcp dot org
We always appreciate constructive feedback.

It appears, as someone has already pointed out, that it is a market issue, not a technical one. Borland voted yes, which is remarkable. And JBoss Inc. voted no, unlike Apache. Which can lead to malicious thoughts...

You have highlighted exactly why this is such an important issue for the JCP. I am not going to suggest that the initial vote against JDO is market driven. I have no evidence for that. The problem for the JCP is that, as currently organised, decisions can, as you say, can lead to malicious thoughts. If JDO 2.0 is voted down, I believe the reputation of the JCP will be irreparably damaged.

It appears, as someone has already pointed out, that it is a market issue, not a technical one. Borland voted yes, which is remarkable. And JBoss Inc. voted no, unlike Apache. Which can lead to malicious thoughts...

You have highlighted exactly why this is such an important issue for the JCP. I am not going to suggest that the initial vote against JDO is market driven. I have no evidence for that. The problem for the JCP is that, as currently organised, decisions can, as you say, can lead to malicious thoughts. If JDO 2.0 is voted down, I believe the reputation of the JCP will be irreparably damaged.

One of the reasons for the NO vote on our end was that both JSR's were supposed to work together. JSR-220 complied with this mandate from Sun by inviting JDO experts to JSR-220. There was little to no compromise on the JDO side and it seemed to me at least, they just plowed ahead with whatever they were doing with little regard to 220.

Even with the commoditization of the J2EE market, companies are spending billions of dollars on J2EE solutions. Ask yourself this, what is the size of the JDO market? What is the size of the JDO userbase as compared to EJB? EJB + Hibernate? EJB + Hibernate + Toplink? After answering these questions honestly, you should rethink on who should be making compromises here. Until the NO vote, JSR-243 has basically ignored 220 while 220 has been forced to work with JSR-243.

So, it boils down to, why should the compromise be one-sided? Especially when one of the markets is orders of magnitude larger than the other?

If you reread the comments of the JDO 2.0 vote, I think you'll see this reflected in the vote comments which basically boiled down to: JDO, EJB, Sun, get your act together and cooperate instead of doing your own thing.

Bill

One of the reasons for the NO vote on our end was that both JSR's were supposed to work together. JSR-220 complied with this mandate from Sun by inviting JDO experts to JSR-220. There was little to no compromise on the JDO side and it seemed to me at least, they just plowed ahead with whatever they were doing with little regard to 220.

Honestly, I don't understand what you are talking about here. When work on the 220 persistence spec was started, the JDO 2.0 spec was already mostly finished, was it not ? So what compromise should the JDO expert group have done ? Postpone JDO 2 until 220 has delivered a first version of said persistence spec ? And from what I understand, some of the 220 members were once in the 243 group but decided to leave it.

Even with the commoditization of the J2EE market, companies are spending billions of dollars on J2EE solutions. Ask yourself this, what is the size of the JDO market? What is the size of the JDO userbase as compared to EJB? EJB + Hibernate? EJB + Hibernate + Toplink? After answering these questions honestly, you should rethink on who should be making compromises here. Until the NO vote, JSR-243 has basically ignored 220 while 220 has been forced to work with JSR-243.So, it boils down to, why should the compromise be one-sided? Especially when one of the markets is orders of magnitude larger than the other?

Ehem, JDO is application-agnostic AFAIK, i.e. works within EJB and outside of it. So what market is larger, Java or J2EE ? And what about EJB+JDO ? Nobody yet explained why EJB+JDO is bad and a new EJB-Persistance spec is neded.

When work on the 220 persistence spec was started, the JDO 2.0 spec was already mostly finished, was it not ?

I don't think so unless the below links are incorrect.

http://www.jcp.org/en/jsr/detail?id=243

http://www.jcp.org/en/jsr/detail?id=220

EJB3 EDR was out 1 week after JDO 2.0's EDR.

EJB3 JSR was started in 2003
I know we joined the EJB3 JSR in March of 2004.

JDO 2.0 JSR was started in April 2004.

JSR-243 did not have to deal with the inclusion of new experts in September as JSR-220 did. Also, persistence is just a subset of EJB so it is understandable that it would be behind JSR-243 with a public draft.

Bill

I don't think so unless the below links are incorrect.http://www.jcp.org/en/jsr/detail?id=243http://www.jcp.org/en/jsr/detail?id=220EJB3 EDR was out 1 week after JDO 2.0's EDR.EJB3 JSR was started in 2003I know we joined the EJB3 JSR in March of 2004.JDO 2.0 JSR was started in April 2004.JSR-243 did not have to deal with the inclusion of new experts in September as JSR-220 did. Also, persistence is just a subset of EJB so it is understandable that it would be behind JSR-243 with a public draft.Bill

Well, did you read them both ? What parts of the - rather sparse - EJB3 persistence spec extend Hibernate in any way ? You cannot tell me that since April all work of the EJB group was focused on the persistence spec (as opposed - obviously - to the JDO2 group). The 'plowing ahead' simply was finishing the spec that was already pretty much finished from what I can see. So, from your viewpoint, what compromise could the JDO2 group could have done ?<br>
And yes, persistence is a subset of EJB, but why ? Why is EJB+JDO bad ? Please explain as I'm rather looking forward to use JDO2, even in EJB applications.

I don't think so unless the below links are incorrect.http://www.jcp.org/en/jsr/detail?id=243http://www.jcp.org/en/jsr/detail?id=220EJB3 EDR was out 1 week after JDO 2.0's EDR.EJB3 JSR was started in 2003I know we joined the EJB3 JSR in March of 2004.JDO 2.0 JSR was started in April 2004.JSR-243 did not have to deal with the inclusion of new experts in September as JSR-220 did. Also, persistence is just a subset of EJB so it is understandable that it would be behind JSR-243 with a public draft.Bill

As I will remember it, the JSR-243 was ready to go well before it was accepted as a JSR by the JCP. The delay I thougt was common knowledge that it was arranged by the normal "we hate the Java users" guys (JBoss, Oracle, IBM and BEA). So the fact that JSR-220 was "first", I guess was according to their "Kill JDO" plan. I also guess (apologies if I am wrong) that all the guys at Hibernate/JBoss is well skilled in this kind of spin doctor activities.

Also, JDOQL and a JDO 2 is needed regardless of EJB3 since EJB3 POJO Persistence products will have to be co-certified with the whole J2EE stack. As a persistence user I *need* a JSR for POJO persistence that doesn't require a whole J2EE certification. I just want to juse J2SE, Spring/JTA and JDO, and be agile not fragile.

Finally. The agreement as presented publicly by the Sun letter (http://java.sun.com/j2ee/letter/persistence.html) clearly states that the JSR-243 will go through as a part of the agreement, just because of those who prefer the JDOQL qurey style:

As currently planned, the scope of JSR-243 will include maintenance to JDO 1.0.1 and enhancements to JDOQL. Additionally, the JDO expert group will aim to deliver JDOQL that would work with the new POJO persistence model so those with a preference for JDO query style can leverage the new common persistence API. The current JSR-243 specification lead will remain unchanged.

This means to mee that the part of the agreement from the JSR-243 side will include the release of JDO 2.0 within the JCP.

The delay I thougt was common knowledge that it was arranged by the normal "we hate the Java users" guys (JBoss, Oracle, IBM and BEA). So the fact that JSR-220 was "first", I guess was according to their "Kill JDO" plan. I also guess (apologies if I am wrong) that all the guys at Hibernate/JBoss is well skilled in this kind of spin doctor activities.

Not sure this matters (as most of you seem pretty rabid about all this), but I don't think that JBoss was even on the JCP EC till late last year (http://jcpelection2004.org/jcp/election_results).

JDO 2.0 JSR was started in April 2004.

Correction: the JDO 2.0 work commenced in August, 2003, in Washington, DC, during a three-day summit on JDO and its future:

http://www.theserverside.com/news/thread.tss?thread_id=21061

It was attended by many vendors (including TopLink) and independents (of which I was one at the time). I can't tell you why JSR 243 was delayed as an official JSR, as I have not been involved in any of the JCP paperwork.

--matthew

Ask yourself this, what is the size of the JDO market? What is the size of the JDO userbase as compared to EJB?

aren't these supposed to be different markets?

and if you prefer to view them as one market (for whatever reason), why impose this on others too?

Ask yourself this, what is the size of the JDO market? What is the size of the JDO userbase as compared to EJB?

aren't these supposed to be different markets? and if you prefer to view them as one market (for whatever reason), why impose this on others too?

The problem for J2EE/EJB vendors is that JDO is often used for persistence within J2EE projects.

So, of course, it makes perfect business sense to come up with an new API, incompatible with JDO, that can be pitched as the preferred solution for persistence within J2EE.

The more sensible solution would have been for this new API to be a superset of JDO, protecting the investment of thousands of developers who trusted the JCP.

Of course, if this was not possible, then it makes no sense whatsoever to push for a unification of the specs.

I am JDO "enemy", but I think your way to "fight" with JDO is too dirty. If you need JDO market you can try to take it in competition. Politics driven technology has no future anyway. So it is hard to become EJB fan too.

you forgot to mention how microsoft will benefit if jboss and hibernate aren't allowed to gain market share.

jsr220 persistence spec is inferior to hibernate and toplink and jdo and will only help ejb container vendors bind people to thier product. plus, if you haven't figured it out yet, jdo users don't want your stinkin' ejb containers!

afaiks, at http://www.jcp.org/en/jsr/detail?id=220 there is no mention of support outside of the container for anything and i trust you ejb vendors like i trust the devil.

jsr243 is complete and ready and jsr220 ain't, and the agenda of jboss and the other ejb container vendors is crystal clear.

i trust you ejb vendors like i trust the devil.jsr243 is complete and ready and jsr220 ain't, and the agenda of jboss and the other ejb container vendors is crystal clear.

Well said! And if the JCP supports this agenda, it will lose any credibility it had for developers.

If you reread the comments of the JDO 2.0 vote, I think you'll see this reflected in the vote comments which basically boiled down to: JDO, EJB, Sun, get your act together and cooperate instead of doing your own thing.Bill

The problem is that this has nothing to do with either the well-established proposal for JDO 2.0, or the newer proposal for EJB 3.0. These were clearly specified: JDO 2.0 should work to be more integrated with J2EE, and EJB 3.0 has no relevance to J2SE. Perhaps you could explain how proposing a new peristence API (based on proprietary APIs) for EJB 3.0, with JDO already in existence was not 'doing your own thing'?

So, it boils down to, why should the compromise be one-sided? Especially when one of the markets is orders of magnitude larger than the other?

Let me apologise in advance for the comments that follow. I normally try and be reserved and polite. As a middle-aged, mild-mannered developer with decades of experience, I usually try and see all sides of an argument and figure out the best strategy, but posts like the above get me seriously annoyed.

Since when has innovation and excellence (something that Sun has has a reputation for for decades) been based on the size of the market? Well, Bill, by your argument, why don't we just give up Java and all use Visual Basic? What role do Linux and Solaris have in your market-driven world? I honestly hope that this is not a representative view of JBoss in the JCP, because if it is, the JCP is doomed.

Sun has always been an innovator - pushing forward standards for the benefit of the developer, often against the interests of proprietary products and vendors. Sun has been doing this for decades. This is why, for decades, I have been using Sun products and recommending them to others. This is why, Bill, if you are pushing forward your own agenda based on proprietary products (Hibernate) and market size, you are damaging Sun, Java and the JCP.

One of the reasons for the NO vote on our end was that both
JSR's were supposed to work together. JSR-220 complied with this
mandate from Sun by inviting JDO experts to JSR-220. There was little
to no compromise on the JDO side and it seemed to me at least, they
just plowed ahead with whatever they were doing with little regard to
220.

As a developer of data-driven apps, I've watched this JDO/EJB drama
unfold with some interest, and of all the outrageous statements that
have been made, this one has got to take the cake. It's so ridiculous
it's funny.

JDO defined a standard for POJO persistence years ago (JSR 12, no
less). The EJB 3 team completely ignored JDO and decided to define its
own POJO persistence standard. Did you guys appeal to the JDO expert
group to get some of their members on board? No. Did you guys even
accept any of the JDO expert group members that applied to be EJB 3
members, until you were forced to by Sun? No. On the other hand, the
JDO group seems to have actively invited people like Mike Keith from
Oracle and Gavin King from JBoss and even the folks from Cocobase
onboard. This occurred long before the EJB 3 POJO direction was
publicly known as evidenced by
http://www.theserverside.com/articles/article.tss?l=JDO2-Kickoff (no
one knew EJB was going to try to reinvent JDO until just before the EJB
early draft was released much, much later).

Looking at the JCP page, the JDO 2 early spec draft was released June
23 2004 and includes pretty much all the features of the final draft.
Sun's letter wasn't published until September. So, Bill, exactly what
do you propose JDOers should have done to compromise? Should they have
screwed their customers by ripping out features that were already
spec'd out? Should they have waited around another year for EJB 3,
despite the fact that JDO 2 was feature-complete and just in need of
some cleanup? Should they have ignored the fact that EJB 3 doesn't
have some JDO 2 features that JDO customers are demanding? What would
have satisfied you, Bill?

And Bill, what exactly have you done to compromise? You were forced
by Sun to accept some JDO members to your JSR. That's not compromise.
Have you listened at all to the JDO spec members? Considering the
statements made by you and your colleagues at Jboss in public e.g.,
"Hibernate is EJB3", I have a hard time believing that you have any
intention of actually listening to the JDO experts on the EJB 3 team.
Have you adopted JDO 2's XML metadata and mapping syntax to replace the
half-baked stuff in the EJB draft? On the flip side, the JDO draft says
it will use EJB's annotations. Have you created a mechanism to execute
JDOQL through the EJB Query interface? There is already a way to
execute EJBQL through JDO's Query interface. Have you made any attempt
whatsoever to align with JDO APIs? I see several places where JDO has
changed since the early draft to align with EJB APIs.

Also, lets not forget about the numerous compromises made when Gavin
King and Mike Keith were part of the JDO expert group (not the official
JCP crap but all of the JDO 2 stuff that happened for a year before the
official JSR was announced). How were those compromises by the JDO
expert group rewarded? A Jboss and Oracle led effort to create a
separate POJO persistence spec under EJB 3. That is the true source of
the community's confusion.

Seems to me you tried to replace JDO with your own POJO persistence for
no good reason (the alternative is the conspiracy theory that you and
Oracle created your own POJO persistence spec purely for self gain and
to be in control of things), then you ignored JDO until you were forced
to accept some members, and since then you have made no attempt to
align with JDO APIs and in fact have highlighted your lack of interest
in compromise with statements like "Hibernate is a superclass of EJB3
Persistence" at the NE JUG. On the other hand, the JDO team seems to
have invited anyone to join, agreed to help with EJB by joining that
team once they were allowed in, has voiced support for EJB 3, and has
made many changes to align with EJB APIs and execute EJBQL queries.

So, Bill, tell us again about how you've been so willing to compromise
and how JDO 2 needs to be rejected because it ignored you. I'd love to
get another laugh. In fact, let us know what other specs are ignoring
you so we can know what duplicate but Jboss-controlled JCP specs are
coming down the pipeline.

One of the reasons for the NO vote on our end was that both JSR's were supposed to work together. JSR-220 complied with this mandate from Sun by inviting JDO experts to JSR-220. There was little to no compromise on the JDO side and it seemed to me at least, they just plowed ahead with whatever they were doing with little regard to 220.

Bill

An interesting perspective I'd love to explore further. Even more interesting is the fact that I cannot recall a single message from you to either the 220 or the 243 group mentioning your concerns. Maybe we could explore this further in any one of these EGs?

Kind regards,
Oliver

One of the reasons for the NO vote on our end was that both JSR's were supposed to work together. JSR-220 complied with this mandate from Sun by inviting JDO experts to JSR-220. There was little to no compromise on the JDO side and it seemed to me at least, they just plowed ahead with whatever they were doing with little regard to 220.

An interesting perspective I'd love to explore further. Even more interesting is the fact that I cannot recall a single message from you to either the 220 or the 243 group mentioning your concerns. Maybe we could explore this further in any one of these EGs?Kind regards,Oliver

Even though this may not have been made explicit previously, I think the psychology (thats what it is, I think, and then some politics on top of that) behind it was obvious from the outset.

I think the problem started with the letter by Sun, which was taken by the JSR-220 people (and many others, in fact) as a statement that JDO was being faded out, and EJB was the way to go. Understandably, however, the JSR 243 folks read something else into it - after all they have invested years of effort. And so they went "plowing ahead", as Bill puts it.

I think right now there is no easiy way out of this dilemma. My suggestion would be to stick with the statement that EJB3 is the preferred standard for ORM, let the JDO people plow aheaed, and finally let the developer community decide what better fits their needs.

christian

Even though this may not have been made explicit previously, I think the psychology (thats what it is, I think, and then some politics on top of that) behind it was obvious from the outset.I think the problem started with the letter by Sun, which was taken by the JSR-220 people (and many others, in fact) as a statement that JDO was being faded out, and EJB was the way to go. Understandably, however, the JSR 243 folks read something else into it - after all they have invested years of effort. And so they went "plowing ahead", as Bill puts it.I think right now there is no easiy way out of this dilemma. My suggestion would be to stick with the statement that EJB3 is the preferred standard for ORM, let the JDO people plow aheaed, and finally let the developer community decide what better fits their needs.christian

What's strange is that EJB has nothing to do with ORM as such, rather it is a user of ORM when doing CMP. So how could EJB3 be a 'standard' for Java ORM ? ORM is not/should not be restricted to the EJB environment though you could come to think that the EJB3 people want it this way. In fact that was why JSR12 (JDO1) was created in the first place: to create a standard Java API for persistence (not only ORM), and JDO2 is simply the next version of this.

What's strange is that EJB has nothing to do with ORM as such, rather it is a user of ORM when doing CMP. So how could EJB3 be a 'standard' for Java ORM ? ORM is not/should not be restricted to the EJB environment though you could come to think that the EJB3 people want it this way.

I think there is an agreement in JSR 220 that the new persistence API should work with POJOs, and be usable under J2SE only. My statements were made under that assumption, otherwise there would indeed be no point in setting it up against JDO.

In fact that was why JSR12 (JDO1) was created in the first place: to create a standard Java API for persistence (not only ORM), and JDO2 is simply the next version of this.

I have said before that I think the idea a standard API for all kinds of datastores is not a good one. I would much rather have a standard that openly follows the goal of doing object/relational mapping exactly right. In that sense my sympathy is with EJB3 persistence - if and when they get the POJO part right.

christian

I think there is an agreement in JSR 220 that the new persistence API should work with POJOs, and be usable under J2SE only. My statements were made under that assumption, otherwise there would indeed be no point in setting it up against JDO.

Even if it does (and I wont bet any money on it), why should a generic Java Persistence API be part of the J2EE standard ? In fact, I would expect such an API to be part of J2SE at some future time, just like JDBC is already.

I have said before that I think the idea a standard API for all kinds of datastores is not a good one. I would much rather have a standard that openly follows the goal of doing object/relational mapping exactly right. In that sense my sympathy is with EJB3 persistence - if and when they get the POJO part right.christian

AFAIK JDO2 delivers that already (you should try Kodo or JPOX, you would be surprised). And why is a datastore-agnostic API a bad thing? In my experience, most applications deal only with standard persistence (saving and loading objects, querying etc.), and do not need special features that may be offered by a RDBMS or a XML datastore or whatnot. They would benefit a lot from such an API because they do not have to care about where to store the data. After all, there must be a reason that JDBC drivers for text files and excel sheets exists.

And why is a datastore-agnostic API a bad thing? In my experience, most applications deal only with standard persistence (saving and loading objects, querying etc.), and do not need special features that may be offered by a RDBMS or a XML datastore or whatnot. They would benefit a lot from such an API because they do not have to care about where to store the data. After all, there must be a reason that JDBC drivers for text files and excel sheets exists.

ObjectStream is a standard datastore-agnostic API for object persistence in JAVA, JDO adds special features that may be offered by a OODBMS. As I understand it is inspired by ODMG failure.
How EJB3 is better ? Is it good just because CMP has failed ?

Even with the commoditization of the J2EE market, companies are spending billions of dollars on J2EE solutions. Ask yourself this, what is the size of the JDO market?

This is so much bullhockey. The most relevant comparison you could draw would be JDO against EJB3 persistence. Well, the answer to that is that JDO market is infinitely larger than the EJB3 persistence market. Ok, let's try the next most reasonable thing. JDO versus EJB CMP/BMP. Well, we know that for the last few years, everybody has been fleeing EJB persistence in favor of other solutions including JDO. I would be surprised if there were still a large population of people continuing to use CMP/BMP in their EJB container.

Let's PLEASE not confuse EJB with a POJO persistence engine. My mind is still reeling about the fact that in some peoples' heads it somehow makes sense to deprecate a persistence API separate from EJB in favor of one under the sole purview of EJB.

God bless,
-Toby Reyelts

I will try rephrase since I did not make myself clear enough: JDO2 as standards will harm me in the same way as SOAP harms me. If SOAP does not harm YOU it is OK with me. You do not have to understand why JDO hurts me- it is fine. I just want all voices being heard and counted.

Oh my God, JDO is SOOOOOO far from SOAP. SOAP is the EJB of XML. SOAP gets in the way and makes programming harder, and makes interoperability harder (ironically). As a SOAP-hater and JDO-lover, I can tell you for sure that there is no similarity.

-geoff

Some people will never learn!

http://www.lovedungeon.net/humor/comp/macibm.html

Whilst I welcome the JDOCentral initiative, it is much more beneficial for individual JDO users to write to hte JCP executive committee about their company's positive experience of and committment to JDO.

I would encourage NON supporters send emails as well because if only JDO proponent will it might create wrong picture. Better yet to setup public poll for developers where everybody will be able to vote.

I am not JDO fan, but I think JDO 2 is a small step to the "right" direction. Probably nobody from JCP executive committee cares about my vote, but it is positive for JDO.

I would encourage NON supporters send emails as well because if only JDO proponent will it might create wrong picture. Better yet to setup public poll for developers where everybody will be able to vote.

This has to be one of the daftest things I have ever seen posted in a technical form in years, and that is saying something.

here is a hint: if you don't like JDO, don't use it. There are plenty of alternatives. That solves your problems, and let's JDO users get on with solving theirs.

I would encourage NON supporters send emails as well because if only JDO proponent will it might create wrong picture. Better yet to setup public poll for developers where everybody will be able to vote.

This has to be one of the daftest things I have ever seen posted in a technical form in years, and that is saying something.

Indeed, it is saying something to me as well, but probably not what you think.

Konstantin is simply making a suggestion that will help the experts make the decision with as much data as possible. Surely, there is nothing wrong in making a poll as objective as possible... right?

--
Cedric

I would encourage NON supporters send emails as well because if only JDO proponent will it might create wrong picture. Better yet to setup public poll for developers where everybody will be able to vote.

Here is a the online everyone can vote, for or against, it closes in a week:
http://www.sandrasf.com/JCP

And a blog post on O/R vs SQL:
http://www.sandrasf.com/node/35

.V

Here is a the online everyone can vote, for or against, it closes in a week:http://www.sandrasf.com/JCP

The vote so far: 36 for JDO in JCP
8 against JDO in JCP.
So that kind of means that people want JDO in JCP.

(I wont report it again, vote is open till Friday if you care to see the closing score).

.V

Here is a the online everyone can vote, for or against, it closes in a week:
http://www.sandrasf.com/JCP

The vote so far: 36 for JDO in JCP
8 against JDO in JCP.
So that kind of means that people want JDO in JCP.

(I wont report it again, vote is open till Friday if you care to see the closing score).

Vic, judging by those numbers, it actually means that 99.9% of the potential voters figured that it was pointless to participate in the poll.

Just because one can put a poll on their blog doesn't imply that anyone will look at it or should vote on it. Drawing a conclusion from 44 self-elected voters on a blog that's applicable to .0001% of the general population is hardly scientific. Such stunts should remain the sole domain of Gerald Bauer.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters

Drawing a conclusion from 44 self-elected voters on a blog that's applicable to .0001% of the general population is hardly scientific.

Nope, it's just my blog.
But I trust more my 44 # then the 880 # they posted on their site. I too think that 99% just don't care, so how did they get 880?

Suspicion: EJB is one big lie. And... JDO want's to say ... if they can lie, why can't we? Sure, why not.

This is more factual about kind of work I do:
http://www.onlamp.com/pub/a/onlamp/2004/08/05/hierarchical_sql.html

.V

Euclidean geometry is just a sub-realm in a most modern geometry theory.
Newton physics is a specific sub-realm of most modern physics theory.
Our integer system or real number system is just a subsystem or two in current leading edge number theory.
Our three-dimensional or four-dimensional universe view is ...

The relational model, which is basically a two-dimensional universe view, should also be one such in a most modern data collection/retrieval systems theory.

The JDO specification should incorporate a most universal data object model for our posterity, that could subsume relational model, as a forgotten old stratum, under it.

The JDO specification should incorporate a most universal data object model for our posterity, that could subsume relational model, as a forgotten old stratum, under it.

Yes, OODBMS vendors failed to develop model for this stuff (or decided to ignore modeling for complex-of-use reason) and pseudoscientific specifications fail for this reason.

The JDO specification should incorporate a most universal data object model for our posterity, that could subsume relational model, as a forgotten old stratum, under it.

now, would you care to enlightebn us what that new model is that supercedes the relational one, and where I can read up on it?

christian

It is possible to find some kind of model for OODBMS (JDO uses the same concepts, probably it is ODMG tradition)
http://www.cs.sfu.ca/CC/354/zaiane/material/notes/contents.html
But I have never saw formal mathematical models for OODBMS and calculus for scripts to access it.

This JCP thing is getting on my nerves. Big corporations trying to cannibalise the smaller ones.

May be it is time to create an open source clone to JCP where no commercial vendors would be allowed. And, move JDO into it :D

Well, that might be a bit too harsh. But, you get the idea. Say make parallel specs to ALL of the failing specs currently in JCP and encourage open source developers to provide competing implementations!!!

Some how I get a feeling I'll be bashed in this message board :-)

No, I don't think you'll be "bashed". There would be legal and licensing complexities with what you propose, but it would seem that many share your sentiment.

My own view is that we have a process for steering Java technologies, and people who feel this process inadequate should sign up and try to influence it rather than sideline it.

Kind regards, Robin.

No, I don't think you'll be "bashed". There would be legal and licensing complexities with what you propose, but it would seem that many share your sentiment.My own view is that we have a process for steering Java technologies, and people who feel this process inadequate should sign up and try to influence it rather than sideline it. Kind regards, Robin.

But with the JDO 2.0 process at the state it is, isn't this far too late for this particular JSR?

May be it is time to create an open source clone to JCP where no commercial vendors would be allowed. And, move JDO into it :D

So all commercial vendors are evil? If you talk to the other vendors of the JDO Expert Group, I think you will find that the commercial vendors contributed significant resources to the development of the spec--just like the open-source implementers and everyone else.

Now I am not saying they do this only for altruistic reasons, but that still doesn't make them evil.

I am also confident that you will find that similar things are true for other expert groups.

Kind regards,
Oliver
(And, no, I don't work for a commercial vendor.)

P.S.: Join the JCP. Vote in elections.

<blockquoteIf you talk to the other vendors of the JDO Expert Group
Of course, this should have read:
If you talk to other _members_ of the JDO EG...

May be it is time to create an open source clone to JCP where no commercial vendors would be allowed. And, move JDO into it :D

So all commercial vendors are evil? If you talk to the other vendors of the JDO Expert Group, I think you will find that the commercial vendors contributed significant resources to the development of the spec--just like the open-source implementers and everyone else.

Totally true. I am not saying commercial vendors are evil. I do realize their importance in the overall game. I just dont like this spec (and others) being torn to pieces due to differences in their business plans.

Most of the times, JCP specs endup being a compromise (not a technical compromise, but a business one) between all the vendors.

It is becoming more and more hard for me to believe that the specs are created in the best interest of the developer/community. Most of the time, the big companies are trying to mold the specs to suit their interests better...

This JCP thing is getting on my nerves. Big corporations trying to cannibalise the smaller ones. May be it is time to create an open source clone to JCP where no commercial vendors would be allowed. And, move JDO into it :D Well, that might be a bit too harsh. But, you get the idea. Say make parallel specs to ALL of the failing specs currently in JCP and encourage open source developers to provide competing implementations!!!Some how I get a feeling I'll be bashed in this message board :-)

Why not allow commercial vendors? There are many commercial high-quality implementations of JDO, and I'm sure that the vendors providing the implementation would welcome and support standard extensions to JDO 1.0.1, even if these aren't within the JCP and called JDO 2.0

A random on-line petition is truely a silly and pointless exercise. It proves nothing. It's not scientific and there is no indication of quality.

Here is a better quality on-line petition:
  http://www.petitionspot.com/petitions/bringbackmisty

As Robin notes, direct and credible emails direct to the JCP exec comittee are the best hope for JDO. Emails and petitions from "biggunzJDOluver7 at hotmail dot com) are as pointless as a pokemon "save misty" campaign.

 - Don

I would not cry one single tear after JDO. I have put a counter-petition on my blog:

http://www.people4objects.org/Carl/2005/01/jdo-is-dead-rip.html

JDOcentral.com used Microsoft-IIS/5.0 and ASP to build their web site. :D

JDOcentral is in the business of disseminating information through a message board. They purchased what they felt was the best tool for hte job, without being partisan.

TSS, although similarly an information dissemmination portal, is additionally in the business of showcasing Java technology best practice. It is regularly reinvented as technologies emerge, and is presently running as Tapestry on top of JDO (Kodo by SolarMetric).

TSS, although similarly an information dissemmination portal, is additionally in the business of showcasing Java technology best practice.

Robin, what a load of crap. TSS is in the business of driving traffic to their site. Period. Besides, TSS's choice of JDO quite possibly has more to do with Mr. Almaer's membership to the JDO EG than any association to best practice and/or some business deal with KODO. TSS could have just as easily and successfully used Tapestry + Hibernate.

Bill

Hi Bill

I beg to differ. TSS has a history of showcasing technology, and portability, by regularly redeploying itself on different J2EE products etc. Now that they've done it with JDO, it wouldn't surprise me to see them "do it" with something else. All of this is in line with the precident set by the site itself. No doubt in time to come when TSS evolves to use EJB 3.0, Bill Burke of JBoss will claim TSS to have finally seen the light!?

Now that TSS is under new ownership the value of this regular evolution may be reappraised.

Kind regards, Robin.

Robin, what a load of crap. TSS is in the business of driving traffic to their site. Period. Besides, TSS's choice of JDO quite possibly has more to do with Mr. Almaer's membership to the JDO EG than any association to best practice and/or some business deal with KODO. TSS could have just as easily and successfully used Tapestry + Hibernate.

Bill, don't take yourself so seriously. Of course it would have worked fine with Hibernate. As for why Dion made the selection he did, and why he's involved with JDO in the first place, those both are probably related to the fact that it helps to solve real problems that he's witnessed. Many of those problems are the same problems that Hibernate addresses.

At a conceptual level, I fail to see how someone could be pro-Hibernate and anti-JDO, or vice versa. I appreciate that some people have to choose between them, since you should probably pick just one for a particular application, but beyond that it's a bit silly, particularly since over time they've grown to each more resemble the other.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters

Robin, what a load of crap.

Occasionally, I consider using Hibernate. Its a great product. and I hear very good things about it. What helps put me off (apart from my preference for multi-vendor support) is this kind of response from developers (and supporters) of, Hibernate. A more humble and professional attitude might make developers and decision-makers like me more likely to switch, or at least less resistant to the technology.

Occasionally, I consider using Hibernate. Its a great product. and I hear very good things about it. What helps put me off (apart from my preference for multi-vendor support) is this kind of response from developers (and supporters) of, Hibernate. A more humble and professional attitude might make developers and decision-makers like me more likely to switch, or at least less resistant to the technology.

+1

I really really agree on this one. I have also considered Hibernate many times, but since all these people (and specificallly Gavin King) says JDO is bad, I must say that I don't trust the cult behind Hibernate.

Anyone who knows a good ORM when you see one, knows that JDO and Hibernate is based on the same principles with regard to ORM, but with JDO more transparent with regard to the Java language. Since I do have worked a lot (14 years) with other object persistence storages as well, I also now that JDO has much more thought in it without making it more difficult to implement than Hibernate. So I guess Hibernate is good to use, albeit a bit limited with regards to JDO products

Previously I used to say JDO/Hibernate in one breath when talking about ORM, but these days I use to say JDO and a über-hyper-politic-product (almost sect-like) such as Hibernate. It's a little bit longer to say but it's important to say.

Robin, what a load of crap.

this kind of response from developers (and supporters) of,

Right.

Because no one involved with JDO has ever hijacked a forum thread, ranted inappropriately at a conference, hijacked a Q&A session or otherwise weaseled pitable comments at inappropriate times.

Nope. Never happens.

 - Don

this kind of response from developers (and supporters) of,

Right. Because no one involved with JDO has ever hijacked a forum thread, ranted inappropriately at a conference, hijacked a Q&amp;A session or otherwise weaseled pitable comments at inappropriate times.Nope. Never happens.&nbsp;- Don

Don

I understand that it must be hard for you, but at this time this thread is not about TopLink or any issues you may have with people who have spoken out in favor of JDO.

The last few posts were actually an opportunity for the Hibernate community (and, to a lesser extent, the JBoss community or employees of JBoss Inc) to get some market feedback. Why do you feel the need to engage in this (sub-) thread, thereby shifting attention and possible ruin this opportunity for them?

Now it's very easy to brush these remarks (both mine and the ones made before) away or shrug them off otherwise, but thinking about this a little more carefully, people might realize that neither the folks who posted before nor I have anything to gain from saying what we did...

Kind regards,
Oliver

Robin, what a load of crap.

this kind of response from developers (and supporters) of,

Right. Because no one involved with JDO has ever hijacked a forum thread, ranted inappropriately at a conference, hijacked a Q&amp;A session or otherwise weaseled pitable comments at inappropriate times.Nope. Never happens.&nbsp;- Don

You are completely missing the point.

I am a JDO user, yet I have a lot of respect for Hibernate (I personally know of some world-class projects which use it). I have even recommended Hibernate to other developers. Though I am a JDO user, if I came across a JDO vendor who said 'Hibernate is rubbish' I would have little respect for that vendor and would have serious reservations about using their product, because I would not trust a vendor who was stating obvious nonsense. And yet, frequently on forums such as these we see senior people (and not just ranting fans) connected with Hibernate and related products stating things such as 'JDO is dead' or that we should promote technologies based simply on market share (as if market share was ever a measure of quality!), or that 'Hibernate is EJB3', or falsely critising JDO based on a lack of understanding. JDO has certainly had its faults, but so has Hibernate and other products and APIs. As a both a developer and decision-maker, I am increasingly discouraged from personally using Hibernate and related products because I don't see the professional and mature attitude I would expect from a vendor. If there was evidence of a more responsible attitude, which showed more respect for alternative approaches to persistence and a desire to enter into honest informed discussion, I would be far less resistant to using Hibernate myself - a view which I feel is shared by many in my position.

Robin, what a load of crap.

this kind of response from developers (and supporters) of,

Right. Because no one involved with JDO has ever hijacked a forum thread, ranted inappropriately at a conference, hijacked a Q&amp;amp;A session or otherwise weaseled pitable comments at inappropriate times.Nope. Never happens.

You are completely missing the point.

Oh shoot, how could I forget one of the most important points. I forgot to add "...and absoltuely insists on getting in the last word, no matter how absoltuely irrelevant, inane or redundant the point happens to be. Nope. Never happens."

Ah, much better.

 - Don

I forgot to add "...and absoltuely insists on getting in the last word, no matter how absoltuely irrelevant, inane or redundant the point happens to be. Nope. Never happens."Ah, much better.&nbsp;- Don

Well, following that principle...

Let me try and put it more simply, as I seem to have been irrelevant and inane rather than responding to your point.

You said that many supporters of JDO behaved in 'less than professional' [my words] ways at forums and conferences. My point is that of course this kind of thing happens but ... its when senior people and vendors do it that puts me off a product, no matter what side of an argument about technology they are on.

Clear enough?

Perhaps if you are going to reply you could reply to the points I make? You could perhaps argue that you consider the behaviour of vendors and product developers irrelevant? Or that you don't consider rude or innacurate posts to be inappropriate? You might even reply that I am being naive in requiring good manners and intellectual honesty?

Steve,

As a director of development for Toplink, Don goes way back with JDO. Here's some history on Toplink, written by him:

http://www.oracle.com/technology/tech/java/newsletter/articles/toplink/history_of_toplink.html

You can find his blog here:

http://jroller.com/page/dsmith/

Not to defend or impune, but I do get the feeling that he had similar conversations with JDO expert group members before these conversations on TSS. Remember, Toplink at one point was on the JDO expert group.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters

Not to defend or impune, but I do get the feeling that he had similar conversations with JDO expert group members before these conversations on TSS. Remember, Toplink at one point was on the JDO expert group.

I'm not sure I quite understand what is implied by this. If it means that all vendors and sides in the persistence situation often behave like scrapping schoolkids then that is a sad situation. I have obviously been naive in expecting otherwise. Even so, I consider myself a typical developer and IT decision-maker, and I know nothing about private conversations or expert group meetings. All I can see is public statements and comments. The content and nature of those comments is part of the way I judge the quality of the support and personnel involved with a product. Intentionally or not, its part of their marketing.

Steve,As a director of development for Toplink, Don goes way back with JDO.

I remember TopLink from way back, when I was Smalltalk developer.

Perhaps we need to consider non-political reasons as to why the JCP EG wants to say no to a JDO2 standard.....the industry wants one standard for solving persistence, that works with both J2EE and J2SE and the JCP has chosen EJB3.

Manoj Kochhar

Perhaps we need to consider non-political reasons as to why the JCP EG wants to say no to a JDO2 standard.....

Do you know some non-political reason ? It must be very hard to find it, I failed to find non-political reason in any "standard", but probably EJB 3 is an exception, because it is very cool and plain object oriented.

yes.....the industry wants one standard for solving persistence, that works with both J2EE and J2SE and the JCP has chosen EJB3.

If "industry" means EJB vendors then you are right.

...because they chose jdo before, which runs fine in and out of the container.

it's nice to rely on such a stable body for our standards.

Yes, EJB is one of the most stable standards. It was camplex-of-use before, but POJO and IoC fixed it. Probably AOP or MDA will fix it later too.

yes.....the industry wants one standard for solving persistence, that works with both J2EE and J2SE and the JCP has chosen EJB3.

Has EJB always been associated with J2EE? Why suddenly this thing or part of it become J2SE. Is the JCP making itself a joke or what?

Who are missing the point here?

Who are missing the point here?

U.

 - Don

Who are missing the point here?

U.&nbsp;- Don

Don, you are lying.

yes.....the industry wants one standard for solving persistence, that works with both J2EE and J2SE and the JCP has chosen EJB3.

There already is an (as yet unapproved) spec that works with both J2EE and J2SE - it is called JDO 2.0. The approved JDO 2.0 proposal called for JDO to be aligned with J2EE. The EJB3 proposal did not mention J2SE. There was no technical need for a new POJO persistence standard to work on both J2EE and J2SE. If there were any problems to be addressed this could have been done by extending JDO. The fact that JSR 220 did not use an existing JSR standard is not good for the reputation of the JCP.

The merging of JDO and EJB was never even debated. It was just announced one day by the powers that be.

It never really seemed like a good idea to me in the first place.

the debate was just never public - its been on the agenda for a long time.