JDO Expert Says: Have Faith in the JCP Executive

Discussions

News: JDO Expert Says: Have Faith in the JCP Executive

  1. JDO Expert Says: Have Faith in the JCP Executive (74 messages)

    On 18 January 2005 the Public Review Ballot for JDO 2.0 closed with a majority NO-vote. There has been significant discussion of this result here on TSS. Most of the discussion has been constructive, but some of the posters have cast aspersions on the JCP Executive Committee for voting in this way and have suggested that JDO should find a home outside the auspices of the JCP.

    As a member of the JDO Expert Group I must add caution to these views. I have faith that the Executive Committee of the JCP will make the right decision when JDO comes before them, for what might be the last time, in its reconsideration ballot; why can't you the community? And no, I do not know whether JDO 2.0 will be approved as is, whether minor or significant changes will be required, or whether JDO will be terminated. But I do know that the Executive Committee will make the right decision.

    I know this for two reasons. Firstly, I elected them. And so did you. At least, if you didn't, then remember to vote next time and, if you are not yet a member, then be sure to sign up before the next elections to the Executive. (I might want your vote!)

    Secondly, JDO has no future outside the JCP. Despite suggestions that the spec be "donated to open source", the JDO 1.0 and JDO 1.0.1 specifications are, to my knowledge, owned by the JCP. And the JDO 2.0 draft which is under consideration by the JCP Executive is owned by Sun Microsystems.

    This is how the system works. These are the procedures and rules which have given the Java community so much that is good in the last several years.

    You can argue that the JCP process is hard to fathom, but the JCP 2.6 Procedures document is not particularly long and is openly available for all to read (http://www.jcp.org/en/procedures/jcp2). You can argue that Expert Groups should be more transparent and conclude their work more quickly - fair comment.

    But you elected the Executive. The corporate positions are staffed by companies which dedicate substantial internal resources to the understanding of ongoing JSRs and the furtherance of the Java platforms. The individual members provide a particular outlook and perspective which is perhaps less commercially focussed but is deemed to be of equivalent value and weight.

    Finally I and other members of the JDO Expert Group are in the midst of dialogues with the individual executive committee members and the Executive as a whole, with the intention of divining the path which JDO must travel in the next 3 weeks and 5 days in order to succeed in the forthcoming Reconsideration Ballot. Whilst I welcome messages of support for JDO, and also healthy debate about JDO, messages of disrespect to the Executive really do not help me in my task. I have already spoken with several Executive Committee members, and can fully appreciate the justifications which they have given to me regarding their voting decisions. None of the Executive Committee members take their responsibilities lightly.

    So please, whether JDO lives or dies (and I believe it will not merely live but will thrive) "Have faith in the Executive!"

    Robin Roos
    JDO 2.0 Expert Group Member

    Threaded Messages (74)

  2. So please, whether JDO lives or dies (and I believe it will not merely live but will thrive) "Have faith in the Executive!"


    OK. but if JDO dies, I can't help thinking that it will be the result of politics. Perhaps it is because my faith in the Executive is already blown away by the sterile debates between JDO and EJB communities.
  3. Hi Gilles

    Hopefully I can get your faith restored in 25 days time...

    Cheers, Robin.
  4. >So please, whether JDO lives or dies (and I believe it will not merely live but will thrive) "Have faith in the Executive!"OK. but if JDO dies, I can't help thinking that it will be the result of politics. Perhaps it is because my faith in the Executive is already blown away by the sterile debates between JDO and EJB communities.
    Do you think politics can kill good technology ?
    Is it possible to kill RDBMS and SQL ?
    If politics can kill thechnology then I think this technogy was politics itself. Many frameworks live without any political standards and they are not going to die.
  5. Do you think politics can kill good technology ? Is it possible to kill RDBMS and SQL ? If politics can kill thechnology then I think this technogy was politics itself. Many frameworks live without any political standards and they are not going to die.
    Politics CAN in this case kill it - JDO 1.0[.1] is a Java standard, owned by the JCP. This JSR seeks to enhance JDO with many features that current and prospective users need. If this JSR fails the next vote, it dies. Since JDO is owned by the JCP, no independent group can take on maintenance of the standard itself - they can extend it, but those extensions will not be standardized - standardization of features that vendors had to extend their JDO implementation to implement is one of the reasons this JSR exists in the first place - it is a response to the needs the users discovered as they began using the technology. Your statement is true only in that ALL JSRs have an element of politics in them - they can only be maintained as standards via the JCP, and that process involves election of committees and votes on approval. It is possible (though unlikely) that an Executive Committee could shoot down the EJB3 JSR. If they continued to do so, the standard would stagnate, users would move on to other, more vibrant technologies or embrace vendor extensions that add the features they need. Either way, the standard itself DOES die. The technology may live on, in an increasingly non-portable way, but then what was the point of the standard in the first place?
  6. Either way, the standard itself DOES die. The technology may live on, in an increasingly non-portable way, but then what was the point of the standard in the first place?
    I do not know it too. Hibernate and Top Link have many users, Probably it means technology is better if they can sell it without standard.
  7. Since JDO is owned by the JCP, no independent group can take on maintenance of the standard itself - they can extend it, but those extensions will not be standardized

    Not standardized within the JCP. Not all standards exist as JSR - look at Java AOP for example.
  8. Is it possible to kill RDBMS and SQL ?
    Possible? Yes.
    Probable? Not anywhere in the near future.
  9. Missing points[ Go to top ]

    IMO, the NO votes weren't votes to kill JDO, but rather to ask that these communities work together to provide a well integrated persistence solution with J2EE and J2SE.

    I think many members of the JDO community are overlooking the opportunity to expand their user base and market by joining with the EJB/Hibernate/Toplink communitities (which are much much larger BTW) to create a unified specification in JSR-220. We've seen over the past few years a huge consolidation in the J2EE market which has shrunk the number of vendors considerably. For users, a unified persistence specification that covers both J2EE and J2SE, and brings more players into one large market. More competition breeds better solutions. Its a win-win for all.

    JDO is represented heavily in JSR-220 and there's no reason features the JDO community needs can't get into the JSR-220 specification. JDO experts have ALREADY contributed a lot to JSR-220. JDO has been about POJO persistence and with JSR-220 ,you, the JDO community, have a chance to get a POJO solution integrated with the J2EE platform. JSR-220 should be about bringing two separate communities (J2EE/JDO) together.

    Instead of focusing your efforts on getting JDO 2.0 finalized or lobbying EC members, IMO, it may be best for the long run, if you focus your energies on getting the EC and the JCP in general to hasten the release of JSR-220 and J2EE 1.5 in general. A unified persistence message strengthens the Java platform.

    Bill
  10. EJB ist updating, please wait....[ Go to top ]

    IMO, it may be best for the long run, if you focus your energies on getting the EC and the JCP in general to hasten the release of JSR-220 and J2EE 1.5 in general.

    Uhhh, we need to do persistence today and not in 1 year.

    In the long run less choices hurt the consumer (I think Microsoft provides an example of this problem).

    Why are the NO voters so afraid of a little competition?
  11. EJB ist updating, please wait....[ Go to top ]

    Uhhh, we need to do persistence today and not in 1 year.

    +1
    I think this is one of the reasons for strong feelings. There were deficiences in JDO 1 that have been largely addressed by vendor-specific extensions and implemententations of features in JDO 2.0 drafts. We have been waiting a long time for JDO 2.0. The wait for yet another API is very frustrating for JDO users who want to move ahead and I imagine it also is for vendors who would like to be able to label their products as conforming to a standard and not a draft. If EJB 3.0 was only a few months away, there might be less concern.
  12. EJB ist updating, please wait....[ Go to top ]

    .Why are the NO voters so afraid of a little competition?

    Competition is good at the product level. Very bad for specifications though.


    Specifications are about consensus. The specification process is about industries getting together to define a common platform, API, and integration. If you have competing specifications, then you don't have much of a consensus. JDO, Hibernate, Toplink, and yes, even EJB vendors, all have successful products, ideas, and innovations to bring to the table. Let's reach consensus.

    A unified specification increases the number of competitors implementing one specification. This is a HUGE plus for users. Since JSR-220 also will allow vendors to implement persistence only (like JMS does), you should be able to hook in best of breed solutions into any application server for persistence. J2EE vendors don't always have the best components and a healthy sub-component market makes J2EE and Java in general a stronger platform. So, no, we are not afraid of competition, we are embracing it.

    Bill
  13. EJB ist updating, please wait....[ Go to top ]

    Competition is good at the product level. Very bad for specifications though.

    This is a good point. The problem is that there already is a specification (JDO 1) that is out there are used by lots of developers, and there is already a significant commercial investment in it. No matter how good EJB 3.0 POJO persistence is, it may take a long time for JDO users to migrate to this new specification, especially if there is a difference in the feature set. So, there will inevitably be two specifications, at least for a while. This is unavoidable. Even if JDO developers decide to migrate (they won't all necessarily - JDO 1 is not going to vanish from the list of JSRs), if they don't get support for the specification they are currently using while preparations are made for this migration, this will leave a lot of developers feeling let down and abandoned.

    Still, I guess we should wait and see what happens over the next few weeks.
  14. more EJB developers[ Go to top ]

    The problem is that there already is a specification (JDO 1) that is out there are used by lots of developers, and there is already a significant commercial investment in it.

    In your above quote, you could logically replace (JDO 1) with EJB. The thing is, there are more EJB developers and more commercial investment in EJB. The lack of consensus is hurting all parties.

    Bill
  15. The problem is that there already is a specification (JDO 1) that is out there are used by lots of developers, and there is already a significant commercial investment in it.
    In your above quote, you could logically replace (JDO 1) with EJB. The thing is, there are more EJB developers and more commercial investment in EJB. The lack of consensus is hurting all parties.Bill

    The BIG difference is JDO2 is an refinement on JDO1, whereas the new EJB3 pojo persistence(*) is a from-the-ground-up new design. This means that anyone wishing to use the new EJB3 pojo persistence will need to rewrite, so the new EJB3 pojo persistence effectively has ZERO users, developers and production commercial products.

    -dain

    * I'm specifically narrowing this to the new EJB3 pojo persistence since that is what everyone is arguing about.
  16. The BIG difference is JDO2 is an refinement on JDO1

    Robin Roos begs to differ:

    It is not a
    "maintenance" release since it adds capabilities to JDO which were not
    present in the JDO 1.0 and 1.0.1 line of specs."


    Bill
  17. Not new, but standardized[ Go to top ]

    whereas the new EJB3 pojo persistence(*) is a from-the-ground-up new design. This means that anyone wishing to use the new EJB3 pojo persistence will need to rewrite

    Actually, EJB3 pojo persistence is not a brand new design. The early draft was built upon VERY successful proprietary products like Hibernate and Toplink. Since the JDO vendors joined in September, their input was added as well. Furthermore EJB3QL is a superset of EJB2QL and we're working with POJOs here.
    , so the new EJB3 pojo persistence effectively has ZERO users, developers and production commercial products.-dain* I'm specifically narrowing this to the new EJB3 pojo persistence since that is what everyone is arguing about.

    JDO 2.0's O/R mapping is brand new, so, by your definition, there are ZERO users, developers and production commercial products of this very significant feature.

    Bill
  18. Not new, but standardized[ Go to top ]

    there are ZERO users, developers and production commercial products of this very significant feature.

    not true. I use JDO 2 features in production. There are a lot of implementations with many features done.

    exercise the vote is democracy, and have the choice is prerequisite. I want be able to choose JDO or EJB, don't take the democracy with you.
  19. Not new, but standardized[ Go to top ]

    Actually, EJB3 pojo persistence is not a brand new design. The early draft was built upon VERY successful proprietary products like Hibernate and Toplink. Since the JDO vendors joined in September, their input was added as well.

    If this really is the order of events, I find this absolutely astonishing. The implication is that after years of work had been put into the JDO POJO persistence specification, this new design initially ignored this work and also ignored the wide use of JDO, and was based on proprietary products.

    If this is the truth, then I'm afraid this is the point at which my confidence in the Java Community Process ends, as do my hopes that JDO has any future within it.
  20. Not new, but standardized[ Go to top ]

    Furthermore EJB3QL is a superset of EJB2QL and we're working with POJOs here.
    Probably this forum is not the right place to ask, but I want to know why do you need this QL. JDO motivates it as persistent store agnostic query language(it is more pragmatic to implement JDBC driver for some persistent store anyway), but I do not understand how it can be usefull for EJB3, if you are going to support databases only.
    Is SQL wrong language to use for databases ?
  21. Actually, EJB3 pojo persistence is not a brand new design.

    It is illuminating to examine the statements of purpose and the assurances given when JSR 220 and JSR 243 started. To see these, go to the www.jcp.org. JDO is not identified as a spec that will be rendered obsolete by JSR 220. There is no mention of a persistence framework outside of an EJB container. In short, if JSR 220 delivers as promised a POJO persistence service that lives outside of the EJB container, they will have exceeded their authority. On the other hand, JSR 243 is completely within the authority granted by approval of its statement of purpose. The intent expressed in the letter to unify the two persistence standards was based on goodwill. Goodwill certainly seems to be lacking when a JSR that fulfills its promise is shot down for failing to conform to the overreaching goals of another JSR.

    I wonder how the JSR 220 team would feel if another JSR decided that they should be the custodians of container managed transactions and blocked the adoption of JSR 220's work for failure to conform to their evolving definition of what CMT should be. "There should be only one definition of container managed transactions. We haven't quite figured it all out yet, but give us some time and we will. In the meantime, cool your heels because you must conform to our spec. We don't want the users to be confused." Oh yeah!
  22. It is illuminating to examine the statements of purpose and the assurances given when JSR 220 and JSR 243 started. To see these, go to the www.jcp.org. JDO is not identified as a spec that will be rendered obsolete by JSR 220. There is no mention of a persistence framework outside of an EJB container. In short, if JSR 220 delivers as promised a POJO persistence service that lives outside of the EJB container, they will have exceeded their authority.

    Of course, if the POJO persistence mechanism of JSR 220 had, as one might have thought appropriate, been submitted as a separate JSR, the conflict with existing JSRs would have been clear.
  23. JSR 220 Is Weeeaaaak[ Go to top ]

    Any features utside of the J2EE Container, not by definition
    JSR 220 - 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

    JavaTM 2 Platform, Enterprise Edition (J2EE) 1.5.

    JDO/JSR 243 conflicting with EJB3/JSR 220, not by definition.
    JSR 220 - 2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

    No. Developers may continue to freely rely on the existing EJB APIs.

    Stuffing Annotations down our throats, by definition. Personally, I find meta-data in the code makes it much harder to read.

    Protecting the interests of JBoss, Oracle, IBM, etc... You betcha.

    I like the tactic from Bill Burke of trying to rally everyone against the big evil Microsoft in his posts. I recall that IBM was once the bad guy, Oracle is currently, JBoss is trying hard...
  24. JSR 220 Is Weeeaaaak[ Go to top ]

    Jon Kofal makes some particularly interresting observations.

    JDO 2.0 deliveres exactly what was documented in the Java Specification Request authorized by the JCP as JSR-243 and is perfectly on time (Community Review mid 2004, Final early-mid 2005).

    In contrast EJB 3.0, specifically in terms of persistence, goes well beyond the brief which was authorised by the JCP as JSR-220. If the Public Draft of EJB 3.0 was published tomorrow it would be 7 months over its original schedule (Public Review June 2004).

    This is neither opinion nor subjective; I recommend readers take 10 minutes to read each of the referenced JSR's.
  25. JSR 220 Is Weeeaaaak[ Go to top ]

    Jon Kofal makes some particularly interresting observations. JDO 2.0 deliveres exactly what was documented in the Java Specification Request authorized by the JCP as JSR-243 and is perfectly on time (Community Review mid 2004, Final early-mid 2005). In contrast EJB 3.0, specifically in terms of persistence, goes well beyond the brief which was authorised by the JCP as JSR-220. If the Public Draft of EJB 3.0 was published tomorrow it would be 7 months over its original schedule (Public Review June 2004).This is neither opinion nor subjective; I recommend readers take 10 minutes to read each of the referenced JSR's.

    The JSRs make interesting reading, especially after Jon's comments, and they do suggest a way forward, which is to make the situation more symmetrical:

    JSR-243 includes the requirement that JDO be aligned with J2EE. JSR-220 mentions no alignment with J2SE (it doesn't mention J2SE at all as far as I can tell), so cannot possibly act as the unified standard. Why not have a new JSR for a truly unified POJO persistence mechanism that aligns both J2SE and J2EE and deprecates neither JDO or EJB3.0, but is a superset of both? This would allow JDO 2.0 to proceed, and EJB3.0 to proceed, but would give time to clarify the role of a unified API.
  26. more EJB developers[ Go to top ]

    The problem is that there already is a specification (JDO 1) that is out there are used by lots of developers, and there is already a significant commercial investment in it.
    In your above quote, you could logically replace (JDO 1) with EJB. The thing is, there are more EJB developers and more commercial investment in EJB. The lack of consensus is hurting all parties.Bill

    Thanks for replying Bill.

    I am of course not saying that you could replace JDO 1 with EJB. (There is a problem discussing this matter because a range of specifications - POJO persistence, EJBs and more - are being grouped into a single JSR). What I meant is that there already is a widely used JSR for POJO persistence. That can't be hand-waved away or casually dismissed. There are tens of thousands of developers and many large companies with major projects already deployed and in development using this (JDO 1) JSR. If they are like me, these developers have assumed that their adoption of a JCP standard meant that they had made the right decision. If their use of such a widely used JSR is to be deprecated, this will, I believe negatively impact the whole JCP. To be blunt, it is implying that JDO is a flawed specification an was, effectively, a mistake. Why do I think this is implied? For simple reasons - (1) because JDO is not being used as the foundation for the new POJO persistance API and (2) the new API is being positioned as the 'new standard' - in other words, a replacement for JDO.

    I feel that this really is damaging for the JCP. If this happens, why should any trust be put in the process for producing standards, if one of these standards, after having been widely implemented and used, could be later abandoned and labelled as flawed? The causual abandonment of APIs and standards is something we frequently criticise Microsoft for.

    Consider the way this process has worked in other cases. Early versions of J2EE had problems, and there have been many revisons - the EJB specification has changed considerably, especially with EJB 3.0. However, there has always been an effort to ensure that developers and vendors have not wasted their investment. Backwards compatibility was ensured. I feel that a major effort should have been made to ensure that the new POJO persistence specification provided a smooth upgrade (not a 'migration') for current JSR users and implementors.
  27. EJB crowd wants to work for consensus[ Go to top ]

    The lack of consensus is hurting all parties.

    So, Bill, please itemize the things that JBoss, Hibernate, Oracle, etc. have done in the past 5 years to standardize on the JCP sponsored POJO persistence service that many people have worked on called JDO?

    Oh, nevermind, I remember now, you all decided to boycott JDO and do persistence over. Now you demand support from the standard that you jilted. Sort like the man who murdered his parents and asked the court for mercy because he had recently become an orphan, don't you think?
  28. EJB ist updating, please wait....[ Go to top ]

    .Why are the NO voters so afraid of a little competition?
    Competition is good at the product level. Very bad for specifications though.

    Specifications are about consensus. The specification process is about industries getting together to define a common platform, API, and integration. If you have competing specifications, then you don't have much of a consensus. JDO, Hibernate, Toplink, and yes, even EJB vendors, all have successful products, ideas, and innovations to bring to the table. Let's reach consensus.

    So Bill does this mean that JBoss will holdback Hibernate so it can be aligned with EJB3? After all, what’s good for the goose is good for the gander.

    -dain
  29. So Bill does this mean that JBoss will holdback Hibernate so it can be aligned with EJB3? After all, what’s good for the goose is good for the gander.

    You might be interested in our road map: http://www.hibernate.org/About/RoadMap

    Hibernate3 was a major development effort for us during the last year and we made significant improvements. Part of this work was preparation for an EJB3 persistence compatibility, based on the draft that has been released more than half a year ago.

    The EJB3 draft has been available to everyone. It was even mentioned in the often quoted letter from Sun, as the basis for the work on the unified persistence specification in JSR 220. If this isn't enough motivation to work on it and prepare yourself, what is?

    If you are interested, have a look at the EJB3 preview releases from JBoss or the EJB3 Annotation preview we just released. Hibernate3 is in beta and from the feedback we get, in a very good shape and already well aligned. Thanks for asking.
  30. So Bill does this mean that JBoss will holdback Hibernate so it can be aligned with EJB3? After all, what’s good for the goose is good for the gander.
    If you are interested, have a look at the EJB3 preview releases from JBoss or the EJB3 Annotation preview we just released. Hibernate3 is in beta and from the feedback we get, in a very good shape and already well aligned. Thanks for asking.

    I didn't think so.

    -dain
  31. EJB ist updating, please wait....[ Go to top ]

    So Bill does this mean that JBoss will holdback Hibernate so it can be aligned with EJB3? After all, what’s good for the goose is good for the gander.-dain

    Products are not specifications. I will reiterate. The sole goal of a specification is to reach industry consensus. A specification should be held back if it does not reach consensus. Products don't need to be held back because they always have the option of going the proprietary route as Hibernate has since its inception.

    Just as JBoss is a middleware solution that has a J2EE personality, Hibernate is a well architected solution that can implement multiple personalities such as EJB3. (If I remember correctly, that was one of the original goals of your CMP implementation that you failed to deliver on for JBoss.)

    Which brings me back to my original point of consensus. Specifications are meant to bring the industry to consensus. They are meant to provide a market of competing vendors so that users don't have lock in. The more implementors the greater the competition and the better it is for users. The J2EE market is consolidating. Proprietary solutions like Hibernate and Toplink are grabbing market share. JDO has its niche. Together everybody is stronger. Apart everybody is weak and Microsoft just laughs their head off in the background. JSR-220 has JDO vendors, EJB vendors, Hibernate and Toplink. Based on the success and strong participation of these groups that has already gone in the past few months, I know a strong consensus can be made.

    Bill
  32. What about the users?[ Go to top ]

    Hi Bill

    Your post overlooks that fact that there are many JDO users already using JDO 1.0.1 implementations and that many of them are already using JDO 2 features. What do these users do for the next year if JDO 2 is canned?

    It is true that a few JDO EG members are on the JSR 220 EG and are contributing but the fact remains that JDO has many features that are not going to get into the first release of the spec. Some of these features (e.g. support for non-relational stores) are never likely to get into EJB3.

    What do JDO users with Maps in their models do? And what about users with Collections of Strings and lots of JDOQL queries? These things are not going to be in the first release of EJB3 and may never get in.

    Now it is good to propose that the chosen few JDO people on the JSR 220 EG help to work towards EJB3 and the future persistent spec.

    Killing JDO 2 will not help this goal one bit. It will leave a lot of users high and dry and will hurt Java as a whole. It will also damage the image of the JCP.

    Cheers
    David
    Versant
  33. What about the users?[ Go to top ]

    Some of these features (e.g. support for non-relational stores) are never likely to get into EJB3.What do JDO users with Maps in their models do? And what about users with Collections of Strings and lots of JDOQL queries? These things are not going to be in the first release of EJB3 and may never get in.

    If this is the case, then surely the new specification is not a unification, but a replacement. It would be hard for JDO users to migrate to a specification if was not a superset in terms of features.
  34. What about the users?[ Go to top ]

    Killing JDO 2 will not help this goal one bit. It will leave a lot of users high and dry and will hurt Java as a whole. It will also damage the image of the JCP.

    I do agree totally.

    It is clear that JDO is leading the persistence momentum and EJB 3.0 will naturally build on the success of JDO. Thus, stopping or delaying JDO 2.0 will benefit no one; even those vendors who only think of their market share.
     
    As the Apache comment " Let the market Decide", instead of delaying all; at least one year from now; till EJB 3.0 gains some ground, and J2EE loses ground!!!

    -Kefah
  35. Missing points[ Go to top ]

    So in summary, and in an implied fashion, you are suggesting that the EC isn't trying to kill JDO, but that the Java community should allow it to die? It sounds like, indirectly, you would prefer the JSR-243 spec to fail.

    What harm is done by enhancing JDO with needed, standard features and beginning the migration path toward JSR-220 persistence? Developers are starting new development right now, and choosing their approach for persistence. If they need POJO persistence, their choices are JDO, non-standard solutions, or a homegrown solution. Of the three, we're better in the long run if they invest in JDO, because at least JSR-243 is making a best-effort attempt to define JDOQL that is compatible with the shared persistence API. It isn't the exact same spec, but it's closer than the alternatives, and is a step closer than JDO 1.0. Developers aren't going to delay new development until EJB3 is available.

    The goal of the shared persistence model is an excellent, sensible goal, but I see no reason why that future should stifle the present. Vendors and projects could release JDO 2.0 compliant persistence engines within weeks of a finalized spec - these features could be in developers' hands possibly before the next draft of the EJB3 spec is even available, much less submitted for approval.
  36. Giving people what they asked for[ Go to top ]

    Wasn't it the JDO community that was arguing so strongly for a unified persistence spec a few months ago? I'm not sure why there are so many negative voices now when the EC says they want to give people exactly what they were asking for.
  37. Missing points[ Go to top ]

    I think many members of the JDO community are overlooking the opportunity to expand their user base and market by joining with the EJB/Hibernate/Toplink communitities (which are much much larger BTW) to create a unified specification in JSR-220.
    Again: why not the other way around, and have EJB/Hibernate/Toplink communities jump on JDO bandwagon NOW, and have it as the persistence spec, as it is ready and working? Ok, JDO community may not be larger than EJB/Hibernate/Toplink, but at least it is a stablished and working spec. Gavin King himself evaluated making Hibernate JDO compliant some time ago, before all this EJB3 stuff appeared, so this is not just something absurd to ask. I am sure that if Hibernate/JDO integration happened back then, we would not be seeing all this mess now.

    I think no one will ever answer this question: why can't EJB3 follow JDO lead?

    Regards,
    Henrique Steckelberg
  38. Missing points[ Go to top ]

    I think many members of the JDO community are overlooking the opportunity to expand their user base and market by joining with the EJB/Hibernate/Toplink communitities (which are much much larger BTW) to create a unified specification in JSR-220.


    JSR 220 will proceed regardless of whether JDO 2 exists. From what I've read, many relational JDO vendors have already pledged to support JSR 220 in additional to JDO 2; in fact they've said they'll offer the ability to switch between the APIs effortlessly at runtime. In effect they will offer the perfect migration path. So JSR 220 is alive and well and slated for early 2006. How does attempting to kill JDO 2 now serve the Java community?
    More competition breeds better solutions.


    Irony++
    JDO is represented heavily in JSR-220 and there's no reason features the JDO community needs can't get into the JSR-220 specification.


    Members of JSR 220 have already said that 220 will not consider non-relational storage and will not use JDOQL. JSR 220 seems to have less flexible ORM and eager fetching than JDO users are used to. JSR 220 does not meet the needs of JDO 1 users; on the contrary, it forces them to wait another year for any persistence progress, then completely replace their existing persistence code with a new and unproven solution that doesn't necessarily even support their requirements. JDO 2, on the other hand, gives JDO 1 users exactly the features they are demanding now, and a clear migration strategy to JSR 220 if they choose to use it in the future. JDO 2 also meets the needs of people who have to access non-relational stores, now and in the future.
    JDO experts have ALREADY contributed a lot to JSR-220. JDO has been about POJO persistence and with JSR-220 ,you, the JDO community, have a chance to get a POJO solution integrated with the J2EE platform.


    You make it sound as if you're trying to unite everyone, but you're the one pitting the sides against each other. The community for the most part isn't suggesting JSR 220 be killed. The community wants JDO 2 now, and if JSR 220 is released on time and widely adopted, so much the better. There is no conflict here. It isn't an either-or choice. As you say, JDO experts are contributing to JSR 220 as we speak; obviously they don't see a conflict. When you try to create a conflict where none exists, is it any wonder that people interpret this as a political move?

    JDO 2 benefits users, and harms no one (except possibly EJB vendors who want everyone using their products until JSR 220 is finalized). JDO 2 does not hurt JSR 220. A "no" vote on JDO 2 is a vote for politics over good technology and the good of the Java community. I sincerely hope that the EC reverses its vote in the upcoming reconsideration ballot. Not because I think a "no" vote will kill JDO -- JDO is too strong for that, and too good a migration strategy to JSR 220 -- but because it will shake my faith in the JCP.
  39. That's exactly what JDO was suppose to prevent, the only reason JBOSS is on this JSR is to kill JDO. I don't see another explanation for you actions and subsequent damage control attempts.
  40. It is a failed technology.

    Leave large database management to a mature industry - DBMS.

    Gemstone, Versant, and many others have failed to realize that unless Oracle, IBM, and/or Microsoft embrace Java Data Objects JDO is dead.

    RDBMS are tried and true. O/R mapping is maturing. JDO is a technology that detracts from J2EE.
  41. Hi John

    In what way does JDO detract from J2EE?

    Thanks, Robin.
  42. It is a failed technology.Leave large database management to a mature industry - DBMS.Gemstone, Versant, and many others have failed to realize that unless Oracle, IBM, and/or Microsoft embrace Java Data Objects JDO is dead.RDBMS are tried and true. O/R mapping is maturing. JDO is a technology that detracts from J2EE.

    Not all developers code for J2EE, or large RDBMSes. There is a need for a persistence technology outside of J2EE and that can be used for a wide range of storage technologies. This is what JDO can be used for.

    JDO has been of benefit to J2EE. It is a simple API that can be used very productively with many aspects of J2EE, even with EJBs.

    To describe a techology that is in use by thousands of developers, has dozens of implementations and is supported by large vendors as 'failed' is, I think. to misuse the word.
  43. It is a failed technology.Leave large database management to a mature industry - DBMS.Gemstone, Versant, and many others have failed to realize that unless Oracle, IBM, and/or Microsoft embrace Java Data Objects JDO is dead.RDBMS are tried and true. O/R mapping is maturing. JDO is a technology that detracts from J2EE.
    The same can happen with EJB3 too. Scientist and RDBMS vendors work decades to make things usefull, politicans decided to do it better using keywords. It is very silly to ignore science, any attemt to avoid it can fail. Keword is short term solution to sell crap. Keword users do not care about dead keywords.
  44. An example of why JDO is needed[ Go to top ]

    Scientist and RDBMS vendors work decades to make things usefull

    As you mentioned Science...

    Here is an example of why JDO is useful. One of the projects I have been working on is the development of software that processes scientific data, performing simulations and showing the results of statistical analysis. This software will run as a J2SE program on PCs and workstations. It will need to load data and configuration settings, and store results and intermediate calculations. The way these are stored could depend on how the customer wants to use the program. They may be loaded and stored as XML, CSV, or in tables in a relational database so that a large volume of results can be efficiently searched and related with other data. In future I might wish to provide the functions of the software as a web service, in which case I would want it to work in a J2EE environment. I would even like the possibility of scaling the software down to it was available in J2ME. This is not a hypothetical example!

    JDO is perfectly suited for this. A POJO persistence API that works only with RDBMSes and requires Java 1.5 would be of little use. This is why the EJB3.0 POJO persistence API should not become the single standard.
  45. An example of why JDO is needed[ Go to top ]

    Yes, text file parsing is a science too, but this problem was solved many years ago ( It is based on fine automata theory )
    Do you have mathematical model for "Transparent Persitence" ? How is it possible to invent calculus like JDOQL or EJBQL without it ?
    I can not trust it, sorry.
  46. RDBMS are tried and true. O/R mapping is maturing. JDO is a technology that detracts from J2EE.

    RDBMS are tried and true. O/R mapping is maturing. JDO is a technology that provides O/R mapping for RDBMS.

    Make your own conclusions.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  47. So much wrong[ Go to top ]

    It is a failed technology.Leave large database management to a mature industry - DBMS.Gemstone, Versant, and many others have failed to realize that unless Oracle, IBM, and/or Microsoft embrace Java Data Objects JDO is dead.RDBMS are tried and true. O/R mapping is maturing. JDO is a technology that detracts from J2EE.

    Wow. There's just so much wrong in these statements, I hardly know where to begin.
    It is a failed technology.
    Ummm, sure. I'll give myself a note to let the thousands of happy JDO users (myself included) know that.
    Leave large database management to a mature industry
    You fail to understand what is going on here. JDO is primarily being used as an ORM. IBM, Oracle, and Microsoft are not well-established vendors in ORM.
    JDO is a technology that detracts from J2EE.

    /rant on

    Sure... I can see how not tying a technology directly to the J2EE stack could be really confusing and detracting. I mean, JDO's ability to seamlessly work both inside and outside a container as a persistence service - wow, terribly distracting. I hereto declare that all XML JSRs should be hereby revoked, because their ability to parse and manipulate XML content both inside and outside the container detracts greatly from J2EE. We should instead, develop totally new and obtuse XML specifications that are less powerful and, even though they must work outside of a container, will live as a component of the J2EE spec. Surely customers won't be confused by the fact that a service totally orthogonal to J2EE is being defined by J2EE.

    /rant off

    God bless,
    -Toby Reyelts
  48. So much wrong[ Go to top ]

    I can see how not tying a technology directly to the J2EE stack could be really confusing and detracting. I mean, JDO's ability to seamlessly work both inside and outside a container as a persistence service - wow, terribly distracting. I hereto declare that all XML JSRs should be hereby revoked, because their ability to parse and manipulate XML content both inside and outside the container detracts greatly from J2EE. We should instead, develop totally new and obtuse XML specifications that are less powerful and, even though they must work outside of a container, will live as a component of the J2EE spec. Surely customers won't be confused by the fact that a service totally orthogonal to J2EE is being defined by J2EE./rant offGod bless,-Toby Reyelts

    Since you cant use java.io inside EJBs, and unless you use EJB3 to store XML content, XML apis should be all revoked. I wonder how could we live without EJB3 until now?
  49. It is a failed technology.
    Gee that's what most companies think about EJBs, and tacking a "3.0" on the end won't change many minds no matter how much it has improved.
  50. You gotta have Faith[ Go to top ]

    [queue George Michael song]
  51. I won't have faith just yet, but I'll wait and see what comes out of it. I commend you for your committment to this spec, as well as your diplomacy in handling the numerous wrinkles that have cropped up throughout the JDO 2.0 cycle.

    That being said, the overwhelming defeat of the JSR before the Executive Committee certainly has me on edge. I know you'll be doing your best to work with the EC to make sure the next vote doesn't bury JDO 2.0. The EC will lose a lot of credibility in my eyes, however, if they either kill the proposal with another no-vote, or if their objections insist on a version of it that is effectively crippled. The key objection raised in the recent vote seems to be that the spec isn't more compatible with a spec that hasn't even been defined yet (the EJB3-related persistence spec). It's plain for me and everyone else to see that you and the Expert Group have been in close contact with the EJB3 EG, and both groups are now working toward a common goal.

    The objections are absurd - you should comply better with a partially-existent standard that may still change significantly, or else. They can't see the spec for what it is - an upgrade for existing users and prospective users for whom shortcomings in the initial JDO spec were obstacles to agoption, and a migration path to unified Java persistence. JDO 2, as proposed, is the spec equivalent of a software "service pack". The EJB3-related persistence spec is the new major release, and JDO can only be fully compatible with it once it is fully defined. Even Microsoft isn't myopic enough to cancel service packs on Windows XP because the features might not be fully compatible with Longhorn.
  52. JDO2 is what we need[ Go to top ]

    Even Microsoft isn't myopic enough to cancel service packs on Windows XP because the features might not be fully compatible with Longhorn.
    I totally agree.

    Mhh I´m doing some refactoring here , and you know what? , something "smells" bad in the JCP.
  53. JDO2 is what we need[ Go to top ]

    Even Microsoft isn't myopic enough to cancel service packs on Windows XP because the features might not be fully compatible with Longhorn.
    I totally agree.Mhh I´m doing some refactoring here , and you know what? , something "smells" bad in the JCP.

    yeah, JCP != JAVA.
  54. With the admission that I did express my fear directly to the Executive Committee that JDO 2.0 wouldn't be approved, I will start to have more faith from now on. Honest!

    I would though like to state my view of the short term problem with the JDO 2.0 and the long term future of both JDO and EJB POJO persistence. I will do this by this two questions:

    Q1: Is a release of the current JDO 2.0 spec a threat to the convergence of JDO and EJB POJO persistence?

    I think (and hope) no:

    The immediate problem: JDO 2.0 is ready as we speak for both products and users, with little or no lag time from spec release to products. Expert Group and Executive Committee must know (and perhaps do - faith, faith) that it is not only about finding the perfect future, it's also to maintain and keep current specs updated to be in par with the current products and existing market. If remaining harmonisation will be needed (which is very likely) that should go into JDO 2.1 or JDO 3.

    JSR-220 is not here yet. Maybe JBoss/Hibernate people disagree, but I have lived through the experience of veerrryyy long lag time by the big vendors when going from finalised spec to real production worthy products (JDK1.2 took 2 years for IMB to realise, how many J2EE 1.4 products are in heavy production use at the moment, etc.?).

    JSR-220 will need it's time. We who use JDO needs the JDO 2.0 spec now. Convergence between the two will not fail because of releasing JDO 2.0.


    Q2: Will JDO and EJB POJO persistence converge totally within the JCP?

    I think (and hope) no:

    We have (and will have for a very long time I think) two types of personalities when doing persistence with Java: The Data Modeler/Mathematical Query Thinker/The SQL People on one side, and the Object Modeler/Object-Navigational people on the other side. Of course its best to know both sides, but the personal design and programming style will almost always lean towards one of the sides.

    The almost war-like discussions prove this I think, and the reason for this ugly discussions is probably that there is a believe that there will be only one of the two personalities that will be allowed to exist within the JCP, and hence someone will have to win or loose. I don't think that is necessary. So, making these two personalities to agree in one single spec, I think is as impossible to make Palestine and Israel to become one cosy common state, the two sides do really have different cultures, which should both be respected.

    Therefore I think it looks healthy with two specs, but with as much co-operation and convergence as possible between the two. JSR-243 for the object-navigational people and JSR-220 for the mathematical/SQL people. Since the only big difference between the two seems to be:

    Query language style

    Relational DB data store only with focus only on ORM, respective Any data store (OODB, flat-file, RDB, etc.)

    Despite the differences above, there are many parts where collaboration and convergence ambitions between the two specs really will be a big benefit for both the community, users and product makers regardless of personality. For example, the JDO product vendors don't seem to hesitate to use the new common ground between the two specs to make a common ORM engine and sell both API:s.

    Best Regards,
    Johan Strandler
    Smart Connexion
  55. JDO has no future outside the JCP. Despite suggestions that the spec be "donated to open source", the JDO 1.0 and JDO 1.0.1 specifications are, to my knowledge, owned by the JCP. And the JDO 2.0 draft which is under consideration by the JCP Executive is owned by Sun Microsystems.
  56. JDO has no future outside the JCP. Despite suggestions that the spec be "donated to open source", the JDO 1.0 and JDO 1.0.1 specifications are, to my knowledge, owned by the JCP. And the JDO 2.0 draft which is under consideration by the JCP Executive is owned by Sun Microsystems.

    Many vendors have already extended their JDO 1.0.1 implementations with features similar to JDO 2.0. If these vendors collaborated then these extensions could possibly be standardised without conflicting with the JDO 2.0 draft (if that was going to become an issue) and products could be labelled (for example) 'JDO + JOPE' compliant (JOPE is a hypothetical acronym - 'Java Object Persistence Extensions'). JDO 1.0.1 is a finalized specification. That is not going to change. There is no possibility of future versions of JDO outside the JCP, but as far as I know there is no reason that a multi-vendor specification ('JOPE'?) for an API that can be used in addition to JDO 1.0.1 could not be developed. I have not looked into this in depth, so I could be wrong...
  57. Hell no! We won't go![ Go to top ]

    products could be labelled (for example) 'JDO + JOPE'

    Hi Steve,

    Interestingly, the JCP and Sun don't own the term 'JDO' (thanks to Castor's prior use), so one possible label is simply "JDO 2".

    If an alternative standards process was to take the current draft spec and give it a quick revision and bring the current JDO vendors along, I think we would see some blood on the streets before long. Those opposed to JDO will not lose quietly.

    I applaud Robin's and others efforts to persuade the members of the EC. Some of them don't have any skin in the game, so they may be persuadable. But there is a history to this dispute, and that history tells me that we are in a fight here, not a debate.
  58. Hell no! We won't go![ Go to top ]

    >Hi Steve,Interestingly, the JCP and Sun don't own the term 'JDO' (thanks to Castor's prior use), so one possible label is simply "JDO 2".

    Heh, well, my vain attempts to introduce an new acronym look short-lived!
    If an alternative standards process was to take the current draft spec and give it a quick revision and bring the current JDO vendors along, I think we would see some blood on the streets before long. Those opposed to JDO will not lose quietly.

    There are many de-facto standards outside the JCP that have been very successful. Look at Eclipse, and the associated plug-ins API for example. Also, JDO has a lot of money behind it in terms of vendors who sell implementations, and a large developer community.
    I applaud Robin's and others efforts to persuade the members of the EC. Some of them don't have any skin in the game, so they may be persuadable.

    I'm afraid I am past caring. Even if this JDO 2.0 draft is passed, it's clear that there is little place for major aspects of JDO in this new so-called 'unified' specification.

    Unless there is a dramatic (and extremely unlikely) change of direction by the appropriate people (Sun? The JCP?), then if a truly general-purpose vendor-neutral and datastore-agnostic POJO persistence specification is to have a future, it is obviously not going to be within the JCP.
    But there is a history to this dispute, and that history tells me that we are in a fight here, not a debate.

    Absolutely. It seems like an attempt to abandon previous JCP defined standards (and those who trusted those standards) and tie persistence as much as possible to J2EE.
  59. Hell no! We won't go![ Go to top ]

    I like what you said.
    I think this is a huge problem and EJB folks are just trying to kill JDO2, it is clear.
    Now I don’t believe in any Integration between JDO and EJB3, it is just a dirty war commanded by big database vendors and its friends.
    I don’t know why so many people from the JDO community are so quiet.

    JDO has a large developer community and users don’t want to abandon it.
    Perhaps the next step is that JDO Vendors should make some effort and should do something like a joined declaration explaining there position.
    And defend their clients.
  60. Hell no! We won't go![ Go to top ]

    I like what you said.I think this is a huge problem and EJB folks are just trying to kill JDO2, it is clear.Now I don’t believe in any Integration between JDO and EJB3, it is just a dirty war commanded by big database vendors and its friends. I don’t know why so many people from the JDO community are so quiet. JDO has a large developer community and users don’t want to abandon it.Perhaps the next step is that JDO Vendors should make some effort and should do something like a joined declaration explaining there position.And defend their clients.
    Probably users do not care about JDO problems, they just need the last big thing, EJB3 is a better keyword.
  61. Hell no! We won't go![ Go to top ]

    IBM developed swt , I wonder: is that an overlap with any existing java technologies ?

    So... this is just a war against JDO!
  62. It's amazing how many people just cannot admit any benefit of using any ORM solution at all and stick with plain old SQL instead. That can be compared only to number of developers that stick with HTML to generate user interfaces.

    Why we are using Java with all that restrictions, like strong types, no goto and so on, instead of use plain, old simple and incredibly fast assembler?

    Seriously, this discussion now really hurt users, personally I will stick with Hibernate (despite I really know that JDO 2 is technologically superior) for next projects, unless some miracle happened.
  63. personally I will stick with Hibernate (despite I really know that JDO 2 is technologically superior) for next projects, unless some miracle happened.

    Hibernate is good, but if you want to use most JDO 2.0 features, there are already plenty of products (including the free JPOX) that you should look at. It's just that these products can't be labelled as 'conforming to a JCP standard', (although if this current mess over the JDO 2.0 JSR continues that could well be a devalued phrase).
  64. Alternatives to JDO[ Go to top ]

    JDO is one of the main attractions of Java platform for us. If it is voted down, java will loose good deal of its appeal for us.
    There are several pretty good ORM (object relational mapping) products for .net and with .net 2.0 and VisualStudio 2005 it becomes a very viable alternative for rich client development
    Not to say that MS is readying their own ORM
    We will definitely explore these options given uncertain state of Java persistence specs. This standards and JCP business gives specific JDO products less chance to survive then if there were no standards at all. If there were no standards – the best products would capture the market (which is ripe for ORM solution). With specs some foreign powers get undeserved lever they use in the name of Java Comunity
  65. Alternatives to JDO[ Go to top ]

    JDO is one of the main attractions of Java platform for us. If it is voted down, java will loose good deal of its appeal for us. ...

    Alex,
      I've investigated .Net ORM solutions. The best ones (at the best price) are conversions of Java ORMs. And all of the current .Net ORM solutions do not adhere to any "standard". So no need to dump Java for that reason.

      As for .Net 2.0 and VS.Net 2005, still not sure when that will come out. And it still doesn't have the support and flexibility that Java and its plethora of IDEs have. (I develop and maintain applications for both platforms).
    Not to say that MS is readying their own ORM
    They are readying their own.(Is that what you meant?) Of course it ties you to Windows, but if you don't mind that, go for it.
    the best products would capture the market
    Unfortunately that is seldom true. ie VHS, PCs, IE, Windows, NTSC (in the US) ... None of these were the "best". At least not at first and not always.
  66. JDO became a Fuel Cell engine[ Go to top ]

    I think situation with JDO is similar to FuelCell engine now. It can deliver very clean solution to the market BUT because of the existing OIL industry and deployed infrastructure its way to the market is slowed artificailly (since OIL guys have a huge lobby in the goverment)

    Nothing new in this... pure politics. I think they killed JDO when it was decided to "assimilate JDO" into "EJB3POJO"...
  67. Why not the other Way ?[ Go to top ]

    After following the discussion of the last couple weeks and beeing heavly envolved as a former JDO Vendor Developer and now a JDO Enterprise Application Developer in my eyes there is only following good and clear solution:

    Throw the EJB3 Persistence Spec away and use JDO 2.0 as the persistence API.

    Add under the Scope of EJB3 all the needed Enterprise features which many JDO Vendors have already added as Vendor Extentions like:
    Distributed Cache, Distributed Transaction etc.

    So the Basic Persistence Spec/API is JDO 2.0 and all the Enterprise stuff is EJB3.

    mfg
    Christian
  68. Why not the other Way ?[ Go to top ]

    Throw the EJB3 Persistence Spec away and use JDO 2.0 as the persistence API.Add under the Scope of EJB3 all the needed Enterprise features which many JDO Vendors have already added as Vendor Extentions like:Distributed Cache, Distributed Transaction etc.So the Basic Persistence Spec/API is JDO 2.0 and all the Enterprise stuff is EJB3.mfgChristian

    There is no way that could happen. Certain people and organisations who have been against JDO for years (because it competes with their products and removes the focus on J2EE) would have to change their minds.

    After all, JDO was around when EJB3.0 was started, and was, apparently, ignored - they started the POJO persistence from scratch. Apparently it was 'better' to base it on proprietary products that competed with JDO.
  69. Why not the other Way ?[ Go to top ]

    After following the discussion of the last couple weeks and beeing heavly envolved as a former JDO Vendor Developer and now a JDO Enterprise Application Developer in my eyes there is only following good and clear solution:Throw the EJB3 Persistence Spec away and use JDO 2.0 as the persistence API.Add under the Scope of EJB3 all the needed Enterprise features which many JDO Vendors have already added as Vendor Extentions like:Distributed Cache, Distributed Transaction etc.So the Basic Persistence Spec/API is JDO 2.0 and all the Enterprise stuff is EJB3.mfgChristian
    I agree. Release JDO2.0 now, and start right away a JDO2.1 JSR coordinated with EJB3 JSR, adressing any needed adaptations/improvements, in order to make it seamlessly integrated with the rest of EJB3 when it's ready.

    The cost of throwing away all that java community have invested in JDO is greater than the cost of making Hibernate/Toplink/etc JDO compliant, IMO.

    Regards,
    Henrique Steckelberg
  70. Why not the other Way ?[ Go to top ]

    I wonder if any one interested in EJB JSR 220 persistence only would be able to buy in a separate package or would have to buy the entire J2EE server?
  71. JBOSS and JDO[ Go to top ]

    An interesting thread to look at in light of this one

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

    It is about how JBOSS chooses JDO as their persistence solution. What happend. JBOSS was all for JDO until they aquired Hibernate. Now all of a sudden they are against JDO and refer on their website Hibernate invented by JBOSS - nonsense.
  72. JBOSS and JDO[ Go to top ]

    I'm working on an app with JBoss app server fronting JDO at the moment. So far it looks like an excellent combination and I haven't yet had significant integration issues. Yes, JBoss used to have their own JDO project. Naturally the JDO 1.0.1 spec does a good job of ensuring that JDO implementations integrate easily with any J2EE 1.3-compliant server.
  73. Response from Google EC member Joshau Bloch[ Go to top ]

    Well, I did my bit - signed the JDOCentral petition and emailed the Executive Committee members and the JCP J2SE/EE group (who might be the same people) through the email on that site.

    I was pretty surprised to get a reply from Joshua Bloch of Google (the only company to abstain) outlining their position. Not sure (or really care) if it was a form letter, but I really appreciate their candor. Here is the transcript:

    -----
    Drew,

    Rest assured, Google does not want to see JDO harmed. We want to see the Public Review Draft tuned to address the concerns of the EC, at which point the JSR-243 expert group can get on with their work.

    Our enterprise Java experts felt that it was in the best interests of both JSRs (220 and 243) to clarify the relationship of the two JSRs going forward, especially with
    regard to persistence and disconnected operation. I see no reason that a revised Public Draft Specification of this JSR cannot succeed.

    To reiterate, our abstention should not be interpreted as as anti-JDO vote; it was not intended to be. It was an honest reaction to a messy situation.

      Regards,

      Josh

    On Thu, 27 Jan 2005 19:52:59 -0800 (PST), Drew
    wrote:
    > My apologies if you already received my previous
    > direct email.
    >
    > I need to do my bit to make sure the right people
    > understand that the reasons offered for voting against
    > JDO 2.0 are not in the best interests of this (Sun,
    > Oracle, Apache) customer.
    >
    > We want transaparent POJO persistence inside and
    > outside of the J2EE container today. JDO 1 gives us
    > that and JDO 2.0 is a very important improvement. At
    > this stage we are very actively evaluating lightweight
    > containers like Spring. We do not want to (a) wait
    > for EJB 3.0 or (b) deal with the inevitable bloat of
    > that spec.
    >
    > Allow JDO 2.0 to pass. Continue with the efforts to
    > develop a decent OR Mapping solution for EJB 3 with
    > both groups. If it really is useful, we will buy it.
    >
    > At the end of the day "opposing the release of JDO 2.0
    > is not in the best interests of those who favor and
    > use the Java platform"
    >
    > Regards
    >
    > Drew Cox

    -----

    Seems reasonable and gives me hope that their is some hope, at least for Google. I strongly ecourage all readers to sign the petition and also write to the Executive Committee.

    Regards
    Drew
  74. Faith is not a strategy[ Go to top ]

    I realize billions disagree but I do not subscribe to the theory that hope and prayer actually achieve anything. I'm sure JDO users (all two dozen) do not want to see the effort they have invested go to waste, but the reality is the market picked Hibernate organically long before it was identified as basis for a Java persistence standard.

    Convoluted, sluggish or overly complicated technology tends not to catch on. You always have defenders such as those who still claim SmallTalk is the cat's meow. They were and are dead wrong. The market knew that at the beginning and later when it faded in to oblivion, its many problems along with it.

    The same will be true for JDO. Good riddance and thank God we have a comittee with the good sense to recognize practical excellence while rejecting steaming piles of empty rhetoric.
  75. Preconceptions block perception[ Go to top ]

    Hi Helmut,

    A couple of corrections. Once, the JDO 2.0 final spec is now being voted on in the JCP executive committee for acceptance. It should be a slam dunk because users have made it clear they want this technology. Prior to your post, this thread concerned the initial vote to accept the the preliminary draft a year ago. That was a bit of a trial because supporters of EJB 3.0 wanted to have the only persistence spec around even though they started a full FIVE years late. Eventually, the community decided to allow both specs to go forward with the expressed desire that the best of JDO would be adopted in EJB JPA, and that eventually, after these revs, there would be only one spec. In fact, JDO has had a positive influence on the emerging JPA spec, as some of the most committed participants have been folks from companies that sell JDO implementations.

    Users will decide which spec and which implementations they like best. Looks like your decision concerning this, and probably many other things, was made a long time ago.

    As to your snide comment about two dozen JDO users, this is absurdly false. There are hundreds, perhaps one or two thousand, companies who are using JDO today to meet their IT needs. A significant number are large Fortune companies. Has JDO taken over the world? Certainly not! Most companies using Java are still using JDBC. For the next couple of years there is ample room for both JPA and JDO to increase their market penetration. Meanwhile users have a wealth of opportunities to improve their development process by adopting a JDO or JPA implementation for their persistence service.

    As for the steaming pile of empty rhetoric, I think you'll find it on your doorstep.


    David Ezzio