Home

News: JDO 2.0 Public Review Ballot votes NO

  1. JDO 2.0 Public Review Ballot votes NO (200 messages)

    The JDO 2.0 Public Draft went before the JCP Executive Committee last week as the JDO expert group requested permission to deliver the Reference Implementation and TCK.

    The ensuing ballot was not approved. Details of the vote are available at http://www.jcp.org/en/jsr/detail?id=243. The comments given by the Executive Committee members make interesting reading, and most of the negative votes arise out of concerns about alignment with EJB 3.0.

    Results
    Sun Microsystems, Inc. voted Yes with the following comment:

    For historic reasons, the Java community has evolved both the JDO and the EJB persistence technologies. Each technology has its own passionate advocates.

    There is general agreement that having two similar persistence technologies is undesirable and that the community should converge on the POJO persistence model as was described in the open letter earlier this year. This convergence is proceeding and on track.

    However, as described in the letter to the community, the plan was to allow evolution of JDO to meet the near term needs of the JDO community, who seek an orderly evolution, not an abrupt end-of-life. JDO 2.0 is significantly scaled back from its original plans, and now delivers minor improvements to JDO in support of the JDO community.

    Separately, there continues to be excellent progress in the JSR-220 (EJB 3.0) expert group on the definition of the new persistence API for Java. Several JDO members have been added to the expert group and the entire group is cooperating to produce a new Java persistence
    specification. An Early Draft Review has been made available with overwhelmingly positive feedback. And there is no doubt that the shared focus going forward is this new POJO persistence API.

    Sun has no particular axe to grind here: we would like to see rapid convergence as much as anyone! But as spec lead for JDO, Sun has no desire to abandon or disenfranchise the JDO community. We would therefore respectfully suggest that it is appropriate to allow some evolution of JDO to meet the needs of the JDO community, while still treating convergence of EJB and JDO as the primary near-term goal.


    Intel Corp. voted No with the following comment:

    We agree with the concerns other EC members have raised in consideration of this ballot. It would be better to take the time needed to ensure changes in the JDO spec fit in with a longer range architecture for persistance.

    Doug Lea voted Yes with no comment.

    Apache Software Foundation voted Yes with the following comment:

    Apache reconfirms it's "yes" vote noting that the letter stated only that "the scope of JSR-243 will include maintenance to JDO 1.0.1 and enhancements to JDOQL", conditions which have been satisfied.

    We agree that having multiple persistence technologies in Java could be confusing to the market. However, we believe that this is something for the market to decide, rather than one company.

    Regarding concerns of alignment, Apache supports there being an alignment of the JDO and EJB persistence specifications, but feel that the proper way to do such a thing is to form a third, independent expert group focused on persistence only, taking input from existing stakeholders like the JDO persistence framework, and the EJB component framework.

    Let a thousand flowers bloom. Let the market decide.

    Hewlett-Packard voted No with the following comment:

    HP is changing its vote to NO after reviewing the concerns expressed by other EC members.

    Google Inc. voted Abstain with the following comment:

    In light of the open letter to the Java Community from Linda de Michel and Craig Russell (http://java.sun.com/j2ee/letter/persistence.html), we believe that the interests of the J2EE platform are best served by the persistence work currently being performed under the auspices of JSR 220. We are worried that the JSR 243 draft in its current form does not address these intents and risks to further fracture the J2EE community.

    IONA Technologies PLC voted No with the following comment:

    Sun's letter that JSR 243 would include maintenance of JDO 1.0.1 and enhancement of JDOQL doesn't seem to be addressed in the Public Draft. Some statements in this version's draft actually appear to belie Sun's email: "Metadata annotations for persistence are being developed in JSR 220. When that specification is final, JDO implementations might support those annotations instead of requiring xmlmetadata. An update to the JDO specification to standardize the annotations is deferred until then." We are concerned about the confusion between the two differing statements of goals.

    JBoss, Inc. voted No with the following comment:

    In September 2004, the JSR 220 and JSR 243 spec leads issued a public letter to the Java Technology Community announcing a joint effort to get a unified specification for Java persistence (http://java.sun.com/j2ee/letter/persistence.html).

    The public letter stated that JDO 2.0 would essentially be a maintenance release of JDO 1.0.1 and enhancements to JDOQL and, more importantly, that they would include migration paths to JSR 220 through 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".

    It is our opinion that JDO 2.0 is much more than a maintenance release and that this will confuse the JCP community further as JSR 220 and JSR 243 were supposed to join forces.

    We believe that JDO 2.0 should start focusing on unifying the API presented in the early draft of JSR 220, to which they can contribute since experts from JSR 243 were invited and now sit on the JSR 220 committee.

    Oracle voted No with the following comment:

    We are concerned that the JDO 2.0 draft produced by JSR 243 does not follow the stated direction that Sun indicated in its open letter of Sept 2004 that "the scope of JSR-243 will include maintenance to JDO 1.0.1 and enhancements to JDOQL". We feel that the duplication that JSR 243 continues to introduce creates confusion in the persistence community and is counter-productive to J2EE.

    SAP AG voted No with the following comment:
    SAP's understanding was that based on the open letter which had previously been published by both Spec Leads, there would be a strong alignment between both JDO and EJB persistence models. We are concerned with the timing of the JDO public release - prior to the EJB public release - as well as regarding the current scope of JDO which does not seem to have followed the objectives that were stated in the previous announcement.

    Apple Computer, Inc. voted Yes with no comment.

    IBM voted No with the following comment:
    The public review draft has done little to address the concerns we originally expressed in the JSR Approval ballot regarding the overlaps between JDO's proposed new capabilities and other similar Java technologies.

    BEA Systems voted No with the following comment:

    BEA shares the concerns voiced by Oracle, SAP, and others that the JDO 2.0 draft produced by JSR 243 does not follow the stated direction that Sun indicated in its open letter of Sept 2004. As a result, the duplication that JSR 243 continues to introduce perpetuates the existing confusion in the persistence community.

    Nortel Networks voted No with the following comment:

    Our understanding is that JSR 243 would follow the approach and policy described in (http://java.sun.com/j2ee/letter/persistence.html).in issued by the JSR 220 and JSR 243 spec leads in September 2004.

    We believe that this joint effort to get a unified specification for Java persistence is the right approach, and support it.

    The letter stated that JDO 2.0 would essentially be a maintenance release of JDO 1.0.1 and enhancements to JDOQL and, would include migration paths to JSR 220 through JDOQL that would work with the new POJO persistence model.
     
    There is significant concern that JSR 243 is becoming much more than a maintenance release, and is not fulling aligning to the stated objectives.
     
    We would like to see the approach to JSR 243 reviewed, with the aim of achieving much stronger alignment and support for a single persistancy model via JSR 220. JSR 243 must be restricted to minimal changes toi the existing JDO for maintenance purposes only.

    Borland Software Corporation voted Yes with the following comment:

    The Java community can only benefit from offering a broader choice for our customers when it comes to a data persistence model.

    Fujitsu Limited voted No with the following comment:

    We believe the relation between EJB should be clarified.
    I expect the JDO Expert Group to submit a revised Public Draft Specification in a few weeks time which better addresses these concerns.

    Kind regards, Robin.

    Threaded Messages (200)

  2. It's important to note that the objections were generally not technical.

    The JDO 2.0 specification is a very fine body of work.

    I'm not sure there will ever be or should ever be a single data persistence specification in Java. Every project has different requirements and every developer has different skill levels and preferences.

    It looks like certain large vendors - that never actually shipped products with JDO support - are using JSR 220 as an excuse to vote against the specification.

    It means that smaller independent software vendors that opted to support the JDO specification (such as CodeFutures) are left in a difficult position.


    Could it be time to move JDO outside the JCP?


    PJ Murray
    CodeFutures
    http://www.codefutures.com
  3. Could it be time to move JDO outside the JCP?

    First tell me what's the advantage for JDO be in JCP today.
    It's important to note that the objections were generally not technical.

    Also note that half of the objectors are EJB vendors.

    And never forget that JDO is a superset of the spec that does not exist today called JSR 220.
  4. JDO is a superset of the spec that does not exist today called JSR 220.

    To be precise the JSR 220 persistence.
  5. It should be the other way around: JSR 220 should be compatible with JDO, as JDO (as a POJO persistence mechanism) came first.

    Regards,
    Henrique Steckelberg
  6. 10 vendors against, 4 in favor, 1 abstained

    Actually it is 9 vendors against, 5 in favor, 1 abstained.

    Yes woted by Sun, Apple, Borland, Apache and Dough Lee.

    It is interested that Sun and Borland woted yes though they are both EJB container vendors.

    Mileta
  7. 10 vendors against, 4 in favor, 1 abstained
    Actually it is 9 vendors against, 5 in favor, 1 abstained.Yes woted by Sun, Apple, Borland, Apache and Dough Lee.It is interested that Sun and Borland woted yes though they are both EJB container vendors.Mileta

    I still make it 10 vendors against, 4 vendors in favor, and 1 vendor abstained (Google).

    There was also one independent vote in favor: Doug Lea

    So the vote ended at 10, 5, 1.

    I make it 10 vendors against (not 9):
    IBM
    BEA
    Fujitsu
    IONA
    Intel
    Oracle
    SAP
    JBoss
    HP
    Nortel

    It might be useful to cross reference the vendors who voted no with the official J2EE licensee list.

    http://java.sun.com/j2ee/licensees.html

    Of course, Sun could not really vote No to a specification where it had provided highly regarded engineer as spec lead and Apache has just agreed to provide a JDO implementation.

    The most significant (and mature) pro JDO comment was from Borland:

    "The Java community can only benefit from offering a broader choice for our customers when it comes to a data persistence model."


    Regards
    PJ Murray
    CodeFutures
    http://www.codefutures.com
  8. Conflict of Interest and the EC?[ Go to top ]

    It would appear that there is a substantial conflict of interest in the voting in question. I am a bit disappointed in the process, and believe a mechanism should be put into place to disallow votes from comittee members with a conflict of interest. These members want to do what is best for themselves and not for Java, as is shown by this vote. On a side note, I'm not suprised I have to figure that the Shadow JBoss/Linda syndicate has been doing their usual behind the scenes back-stabbing effort. Won't Sun just get wise and fire Linda already. This is soap opera is getting a little tired already.
  9. Conflict of Interest and the EC?[ Go to top ]

    It would appear that there is a substantial conflict of interest in the voting in question. I am a bit disappointed in the process, and believe a mechanism should be put into place to disallow votes from comittee members with a conflict of interest. These members want to do what is best for themselves and not for Java, as is shown by this vote.

    I can accept that there may well be valid objections to the JDO 2.0 draft, but I strongly support the idea that there might be conflict of interest problem. The problem arises when members organisations and companies who promote the use of products that compete with the APIs of a JSR become involved with it. Even when the people concerned do good work, surely the question of conflict of interest must inevitably arise? I may be being too cynical. My concerns would be lessened if the POJO persistence of EJB3.0 turned out to be a high-quality superset combining the best features of current persistence technologies such as JDO. My worry is that it will be a subset, dominated by vendor-specific extensions, allowing current proprietary persistence products to claim to meet some kind of minimal standard. I wonder if this is behind some of the objections to JDO 2.0.
  10. Conflict of Interest and the EC?[ Go to top ]

    My worry is that it will be a subset, dominated by vendor-specific extensions
    Then you should express your concerns to the JSR220 EG.

    Can you be more specific? What features do you think are present in JDO2 and not in EJB3?

    Once you have made this list, please post it here and make sure you email it to ejb3-feedback.

    --
    Cedric
  11. Conflict of Interest and the EC?[ Go to top ]

    Hi Cedric

    I will not comment directly on JSR-220 since I have seen no significant material since the first Early Draft was published during JavaOne last year. Members of the JDO 2.0 expert group (appart from the six seconded to JSR-220)do not have access to JSR-220 discussions and works in progress until they are made public.

    However I will point out that many of the standardized but "optional" features defined in the JDO 1.0 specification are now so widely supported by the vendor community that they have been made mandatory in the JDO 2.0 spec. This is a natural progression which happens in concert with the growing maturity of the JDO product space.

    JDO 2.0 also serves to decrease users' dependency on vendor-specifics through the standardization of O/R mapping metadata, advanced query capabilities, and the definition and invocation of fetch groups.

    There will always be proprietary features in products other than the RI. This is natural and good. The specification process should strive continually to raise the bar by standardizing widely needed features. Where this process can leverage implementation experience (by standardizing today what was properietary yesterday) the calibre of the standard is likely to be higher than if all standardization is based upon hypothesis.

    Kind regards, Robin.
  12. Conflict of Interest and the EC?[ Go to top ]

    My worry is that it will be a subset, dominated by vendor-specific extensions
    Then you should express your concerns to the JSR220 EG.Can you be more specific? What features do you think are present in JDO2 and not in EJB3?Once you have made this list, please post it here and make sure you email it to ejb3-feedback.-- Cedric

    As an example, one specific concern is that I have heard that EJB3 POJO persistence does not have good support for persistence of arrays, Collections and Maps, and so imposes restrictions on the design of the object model, in contrast with JDO, where few such restrictions are present.

    However, I do feel that this is the wrong way round. I am the customer for such technologies. I believe that posting concerns on a public forum does impose a responsibility to justify these concerns (as I have above), but surely the potential EJB3.0 implementors and vendors should be doing their utmost to address such concerns. A simple statement along the lines of "we intend that EJB3.0 POJO will be a high quality superset of JDO 2.0 (or equivalent) functionality" would be sufficient. Note that I am not implying that EJB3.0 POJO persistence should implement JDO as one of the ways of accessing the functionality (although I believe that would be highly desirable), only that equivalent (or better) functionality be present.
  13. Conflict of Interest and the EC?[ Go to top ]

    My worry is that it will be a subset, dominated by vendor-specific extensions
    Then you should express your concerns to the JSR220 EG.Can you be more specific? What features do you think are present in JDO2 and not in EJB3?Once you have made this list, please post it here and make sure you email it to ejb3-feedback.-- Cedric

    Support for JDKs before 1.5
  14. Cedric,

    e.g. OneToMany - ManyToOne _forced_ bi-directionality. I _really_ dislike this (having tried the JBoss/Hibernate partial EJB3 implementations, esp. persistence via Hibernate annotations). What is the reason behind this?

    regards,

    Messi

    P.S.: I have mailed this to ejb3-feedback
  15. Conflict of Interest and the EC?[ Go to top ]

    It would appear that there is a substantial conflict of interest in the voting in question. I am a bit disappointed in the process, and believe a mechanism should be put into place to disallow votes from comittee members with a conflict of interest. These members want to do what is best for themselves and not for Java

    Huh? (trying to disguise myself as an American ;-)
    Are you saying that BEA, IBM, Oracle, Sun, etc. are in a conflict of interest because they vote according to what their interests are? I may not be American but us Canucks like to think that we know a bit about democracy as well, and when we vote we vote for our own interests. That is how it is supposed to work (and I think it works pretty much the same in US!). If a company gets a chance to vote then of course it will vote for what it thinks is best for them... and what is best for Java because what's best for Java is best for them. Remember that these companies all make lots of money off of Java and I hope I'm not shocking you when I say that they probably want to make as much as they possibly can. Better Java = more money for big companies. Simple, eh? (oops, my disguise just fell off).
    Won't Sun just get wise and fire Linda already. This is soap opera is getting a little tired already.

    Now you have crossed over from simply not understanding politics (forgivable) to being downright nasty (forgivable, but probably only when accompanied by an apology). There are lots of people that probably should be fired at Sun but Linda is definitely not one of them. She has done what I would consider a rare thing in this industry. Make a list of people that have taken their own previous work and publicly admitted that it was not the right answer, and then volunteered to rip it to shreds and start again doing it all over again, but accepting advice from the leading product experts (aw, shucks). I'm kinda guessing the list would be short.

    -Mike
  16. Conflict of Interest and the EC?[ Go to top ]

    It would appear that there is a substantial conflict of interest in the voting in question. I am a bit disappointed in the process, and believe a mechanism should be put into place to disallow votes from comittee members with a conflict of interest. These members want to do what is best for themselves and not for Java
    Huh? (trying to disguise myself as an American ;-) Are you saying that BEA, IBM, Oracle, Sun, etc. are in a conflict of interest because they vote according to what their interests are? I may not be American but us Canucks like to think that we know a bit about democracy as well, and when we vote we vote for our own interests. That is how it is supposed to work (and I think it works pretty much the same in US!). If a company gets a chance to vote then of course it will vote for what it thinks is best for them... and what is best for Java because what's best for Java is best for them. Remember that these companies all make lots of money off of Java and I hope I'm not shocking you when I say that they probably want to make as much as they possibly can. Better Java = more money for big companies. Simple, eh? (oops, my disguise just fell off)

    I think this analysis of the situation is too simple. It may be good for these companies that Java in general does well, but there may be specific APIs and products that would some companies would not be enthusiatic about. There is no single thing called 'Better Java'. One companies 'Better' is not the same as another's. To give an example, suppose there was a proposal to design a very high-performance relational database engine in Java and to include that database engine with the JRE. This might result in a 'Better Java' for the developer and user, but it would certainly not be considered 'Better' by database vendors! The situation where a conflict of interest might be considered is if people who worked for a database vendor were allowed to assist with the design of this hypothetical database engine.
  17. Conflict of Interest and the EC?[ Go to top ]

    Won't Sun just get wise and fire Linda already. This is soap opera is getting a little tired already.
    Now you have crossed over from simply not understanding politics (forgivable) to being downright nasty (forgivable, but probably only when accompanied by an apology). There are lots of people that probably should be fired at Sun but Linda is definitely not one of them. She has done what I would consider a rare thing in this industry. Make a list of people that have taken their own previous work and publicly admitted that it was not the right answer.-Mike

    Mike-

    First, Linda didn't say it wasn't the right answer, Java developers did.

    Second, you obviously weren't at JavaOne, where Linda led a session on the new persistence, and showed code that was basically identical to the equivalent JDO, yet couldn't bring herself to mention those three letters in that order during *any* part of that speech. Nor did you ask her about it after the session, and get the lamest bull sh*t answer you had ever heard. After that, you obviously didn't spend time watching a session by the JDO spec. leads where they not only mentioned EJB, but when asked about the similiarities, openly admitted that they hadn't been talked to about the new spec., but were more than happy to work together. Now that's why I think Linda shouldn't be working on specifications at Sun. She had a perfectly good spec. to start with, and went out and reinvented the same thing. What a waste of time and effort, not to mention that she has to be forced by higher-ups at Sun to use JDO. You actually think that came about because of what Linda wanted, do you? I can most certainly tell you from the answer I received, that was the *last* thing she wanted.

    I don't care much either way, but I don't want two of the same damn spec. and I think that whatever transparent persistence spec. comes out of this quagmire needs to support non-relational data stores. Pretty simple.
  18. Conflict of Interest and the EC?[ Go to top ]

    Mike-First, Linda didn't say it wasn't the right answer, Java developers did.

    Linda has said this not once, but numerous times at numerous conferences.
    Second, you obviously weren't at JavaOne, where Linda led a session on the new persistence, and showed code that was basically identical to the equivalent JDO, yet couldn't bring herself to mention those three letters in that order during *any* part of that speech.

    I was at that talk and although I disagree that the code was identical to JDO. Nevertheless, I am glad that you saw the similarities because that is exactly the point. When I look at EJB I see definite similarities to both TopLink and JDO because that is what I know. Not only is it natural to compare things to our own experience, but they are all doing POJO persistence, and take my word for it, the solution is pretty much well understood at this point and better at least be similar. I wouldn't expect Linda to mention JDO in her talk on EJB because at that time there was no collaboration between the two JSR groups. If you have gone go any of her recent talks you will certainly hear your favourite three letters.
    Nor did you ask her about it after the session, and get the lamest bull sh*t answer you had ever heard.

    I guess this just reflects our different perspective but the thing that sticks out in my mind about the questions was the number of people that wanted there to be a single spec on persistence. I not only agree with that now, but have always agreed with it. That is the problem that is trying to be fixed here, and tearing down one of the few people that may even have influence to help make this happen is in my view not going to get us there any faster.

    Although I instinctively want to pick apart all of the things that you said that were untrue doing so would be equally unproductive. If you are angry then do what everybody else is doing and blame the EC, or go kick your cat, or whatever you need to do to release steam. Please don't attack individuals for something that is obviously more complicated than what you know or understand.
    I don't care much either way, but I don't want two of the same damn spec. and I think that whatever transparent persistence spec. comes out of this quagmire needs to support non-relational data stores. Pretty simple.

    At last, something that I can agree with. Yes, there should just be one spec, and it should allow all types of data in many types of data stores. I think that will eventually happen, but given that 99% of applications access strictly relational db right now I think that standardized non-relational stuff can wait at least a little more time. We need to see how people are using it before we go off and standardize it, and make the same mistakes that early EJB versions made.

    -Mike
  19. time is now[ Go to top ]

    JDO experts have been participating in JSR-220 since end of Septemeber and their efforts and participation have greatly enhanced the current JSR-220 spec draft. Let's continue to deepen this collaboration so the finalization of JSR-220 can be hastened and the Java community can get what they've been asking for: A unified persistence specification that covers both J2SE and J2EE.

    Bill
  20. time is now[ Go to top ]

    A unified persistence specification that covers both J2SE and J2EE. Bill

    I support the JSR 220 unified RELATIONAL persistence, but JDO is datastore agnostic and should be forwarded.
  21. store agnostic, really?![ Go to top ]

    From what I have seen it looks like smaller vendors deliver ORM solutions with implement JDO API. I have not heard about a single solution that supports full JDO 2.0 (JDOQL) spec on flat files or something else than RDBMS. Even more IMO JDO support for other than RDBMS storages is a gimmick and should be dropped for good.
    I would not object having a decent ORM spec, but combining support for RDBMS and flat files in one spec inevitably leads to: too much to do for JDO to supports full range of operations on flat files (makes RDBMS from JDO) or some compromises and underuse of RDBMS power.

    Maybe JDO should be a spec for non-RDBMS storages, that makes sense for me
  22. I have not heard about a single solution that supports full JDO 2.0 (JDOQL) spec on flat files or something else than RDBMS.
    this has been said many times before, but it still deserves repeating: trying to cover RDBMSs under a unified API for all types of "datastores" was a stupid thing from the outset. The only reasonable way to approach this IMO would have been to separate the spec into different "profiles", as is done in the Java mobile field.
    Maybe JDO should be a spec for non-RDBMS storages, that makes sense for me
    that is certainly a view that could make sense. But as you say, almost all implementations target RDBMSs.

    christian
  23. I have not heard about a single solution that supports full JDO 2.0 (JDOQL) spec on flat files or something else than RDBMS.
    this has been said many times before, but it still deserves repeating: trying to cover RDBMSs under a unified API for all types of "datastores" was a stupid thing from the outset.

    Two days ago I came across a SQL query which I was unable to express in JDOQL and the object model had to be changed in a very specific way to facilitate that particular query. The alternative (which was considered) was to use JDO's capability to express queries in native SQL. In the absence of object model and schema design authority, using native SQL for that single query would have been our fallback position.

    What I find interesting about this is that it's the first time it's happened in 12 months. Since vendors started supporting the proposed JDO 2.0 query enhancements (specifically aggregation and projection) life has become remarkably good in this regard.

    So I don't buy the concept that relational storage is so perculiar that the semantics of object persistence (and object model-based query) cannot be applied efficiently.

    Kind regards, Robin.
  24. Two days ago I came across a SQL query which I was unable to express in JDOQL and the object model had to be changed in a very specific way to facilitate that particular query.
    Probably JDOQL is incomplete. This problem doe's not exist in SQL and I perfer mature query languages, it can be implemented fo flat files too.
  25. So I don't buy the concept that relational storage is so perculiar that the semantics of object persistence (and object model-based query) cannot be applied efficiently.

    thats not what I was saying, really. What I mean is that the relational model is so rich that it would be hard to design an API that supports all its features and can be reasonably implemented on top of other datastores. In practice, I see JDO going the right (RDBMS) way, and I like the API in general, but every mention of "datastore agnosticism" still makes me shudder.

    christian
  26. So I don't buy the concept that relational storage is so perculiar that the semantics of object persistence (and object model-based query) cannot be applied efficiently.
    thats not what I was saying, really. What I mean is that the relational model is so rich that it would be hard to design an API that supports all its features and can be reasonably implemented on top of other datastores. In practice, I see JDO going the right (RDBMS) way, and I like the API in general, but every mention of "datastore agnosticism" still makes me shudder.christian

    This is your conceptual choice and if you like to use different APIs for different datastores, it's fine.

    It's a fact and we can't ignore that JDO has today implementations supporting file, xml and rdbms data store.

    EJB vendors are also shuddered about the range of the datastore JDO permits you to choose.
  27. Why not lock Java to Windows?[ Go to top ]

    So I don't buy the concept that relational storage is so perculiar that the semantics of object persistence (and object model-based query) cannot be applied efficiently.
    thats not what I was saying, really. What I mean is that the relational model is so rich that it would be hard to design an API that supports all its features and can be reasonably implemented on top of other datastores. In practice, I see JDO going the right (RDBMS) way, and I like the API in general, but every mention of "datastore agnosticism" still makes me shudder.christian

    What I do not understand is why you are so hostile towards the datastore independence of JDO. This is like demanding that Java should drop its independence of the operating system and concentrate on Windows only. This way we could drop Swing as well and move to SWT locked onto MFC, which would be so much more consistent and faster.

    Obviously we do not want to do that - and neither will you I believe. The fact is that even among RDBMS implementations there are grave differences. But there are also lots of other datastore implementations out there - not only ODBMS or flat files (which seem to be your major concern, and I agree with you in that I fail to see the point in those), but also XML databases, host access or any technology that someone might come up with in the future.

    The idea behind JDO and its transparent persistence was to isolate the business programmer from the datastore quirks and instead focus on the business problem using the programming language s/he knows: Java.

    Now feel free to flame me.

    Sven Erik
  28. What I do not understand is why you are so hostile towards the datastore independence of JDO.

    I dont know how you get the feeling anyone is hostile. I feel I am part of an informed discussion.
    This is like demanding that Java should drop its independence of the operating system and concentrate on Windows only
    Simple answer would be: no, it is not. They are unrelated issues.
    The fact is that even among RDBMS implementations there are grave differences. But there are also lots of other datastore implementations out there - not only ODBMS or flat files (which seem to be your major concern, and I agree with you in that I fail to see the point in those)
    I wonder how you get to those conclusions about my concerns, and the mood in which I write. I dont see big differences between RDBMSs, and those that exist are well covered by JDBC and existing ORM solutions (the good ones of course still provide access to native features).

    Let me repeat: I (and many others, may I say) need an API that does not make any compromises with regard to the power of relational databases. I have never in my career encountered the need to port my database access code to a non-relational DBMS, and I dont mind at all using dedicated APIs for accessing XML and flat files. Anything wrong with that?
    Now feel free to flame me.Sven Erik
    dear goodness, why in the world should I flame you??

    christian
  29. I would take that a step further and ask *WHY* are these abstractions ontop of RDBMS's needed at all?

    Isn't that what JDBC is for?????

    It amazes me the lengths the Java croud goes to, to avoid having to learn some RDBMS specific SQL.

    What the hell do you people do, sit there all day and switch your app from one database to another such that you need this rediculous level of abstraction?

    Why do you need to see your data as objects? A ResultSet is too hard for you to figure out?

    The Java croud is simply going to bury it self in layer ontop of layer of indirection and abstraction.

    Mike
  30. * abstraction from the underlying sql. with orm one could concentrate on the Object, in an object oriented way instead of having to worry too much about the underlying relational model. Without ORM, stuff like inheritance would required quite a bit of work in one's dao or helper classes that this function is delegated to. Trivial stuff like escaping certain characters in String that could break sqls etc.

    * Object graph navigation comes with orm is nice to have. Else some translation would need to be done, probably ending up with lots of value objects

    * page navitation is essentials. currently (as far as i know) doing pagination with sql is pretty vendor specific, not all dbs have 'limit' like mysql. Of course one could abstract away the sql generation, and make changes as switching db, but why when an orm does this pretty transparently


    Databse independency is crucial if one is working on a product that is to be sold to different clients that have varying environment. Each might want to use different dbs.


    regards
    tmjee
  31. I would take that a step further and ask *WHY* are these abstractions ontop of RDBMS's needed at all? Isn't that what JDBC is for?????It amazes me the lengths the Java croud goes to, to avoid having to learn some RDBMS specific SQL. What the hell do you people do, sit there all day and switch your app from one database to another such that you need this rediculous level of abstraction?Why do you need to see your data as objects? A ResultSet is too hard for you to figure out?The Java croud is simply going to bury it self in layer ontop of layer of indirection and abstraction.Mike


    * abstraction from the underlying sql. with orm one could concentrate on the Object, in an object oriented way instead of having to worry too much about the underlying relational model. Without ORM, stuff like inheritance would required quite a bit of work in one's dao or helper classes that this function is delegated to. Trivial stuff like escaping certain characters in String that could break sqls etc.

    * Object graph navigation comes with orm is nice to have. Else some translation would need to be done, probably ending up with lots of value objects

    * page navitation is essentials. currently (as far as i know) doing pagination with sql is pretty vendor specific, not all dbs have 'limit' like mysql. Of course one could abstract away the sql generation, and make changes as switching db, but why when an orm does this pretty transparently


    Databse independency is crucial if one is working on a product that is to be sold to different clients that have varying environment. Each might want to use different dbs.

    just my 2 cents

    regards
    tmjee
  32. Dear tm jee,
    Trivial stuff like escaping certain characters in String that could break sqls etc.
    have you ever even programmed JDBC ?! If you have then you've not understood a bit from it, if you think you need ORM to escape string values in SQL.
    Also you seem to be hanging out with a terribly brain dead crowd:
    not all dbs have 'limit' like mysql
    How fucking typical for the born with Java and coolest-framework-of-the-month up it's nose crowd. Sends me back to that while(*d++=*s++); piece of code and Joel's subsequent remark, so sad but true:
    <blockquoute>
    I don't care how much you know about continuations and closures and exception handling: if you can't explain why while (*s++ = *t++); copies a string, or if that isn't the most natural thing in the world to you, well, you're programming based on superstition, as far as I'm concerned: a medical doctor who doesn't know basic anatomy, passing out prescriptions based on what the pharma sales babe said would work.
  33. not all dbs have 'limit' like mysql
    How fucking typical for the born with Java and coolest-framework-of-the-month up it's nose crowd.

    Why should there be a problem in pointing out that mysql has deficiencies? The point that was being made was that JDO (and equivalents) allows independence from this. For example subselects have not been around in mysql until very recently. If you use the equivalent of a subselect in the JDOQL, or some alternative, it will convert this to whatever is necessary in mysql to get the job done (efficiently). The alternative is to have a set of specific SQL strings for mysql that are selected by checking the database vendor and version: messy and almost always unnecessary.
    Sends me back to that while(*d++=*s++); piece of code and Joel's subsequent remark, so sad but true: I don't care how much you know about continuations and closures and exception handling: if you can't explain why while (*s++ = *t++); copies a string, or if that isn't the most natural thing in the world to you, well, you're programming based on superstition

    I found this discussion from Joel On Software pretty amusing. I have used C for decades and I always assumed that the example he gave was nothing more than an illustration of the low level at which C operates. A C developer must be able to explain why that sort of thing works, but it should hardly be 'natural', and I would be worried working with or employing a developer who said it was: Its actually an example of a potential buffer overrun! A developer should, of course, use strncpy.
  34. Gosh[ Go to top ]

    Gosh – I've read some amazingly daft stuff on TSS (much of it written by Rolf) but my jaw hit the floor as I started to read through this thread. Screaming, shouting, hurling abuse and yelling "conspiracy" – getting on like a house on fire basically.

    The bringing together of EJB and JDO is something that is desperately needed in the J2EE world and something which many people on TSS and elsewhere have been calling for for a while. It is in hand after years of wrangling, and this is a very good thing. It is simply irresponsible to try and push through another spec which may conflict with the EJB3 API at this point. Take a deep breath, wait for a few weeks, iron out the conflict problems and resubmit the proposal having addressed these concerns. Oh and for goodness sake grow up a bit.

    Sorry to be so grumpy, I've had a difficult week.

    Fred
  35. Why should there be a problem in pointing out that mysql has deficiencies?
    Sorry Steve, but reading the assertion like "not all databases have 'limit' like mysql [does]", and checking out the SELECT syntax gives more/different sense both to his and my words.

    Disclaimer: the text below DOES NOT crap all over any ORM solution.

    Regarding your JDO brings independence and relieves you from the database being a pain in the neck argument, for me that's a bunch of crap, frankly. Notice the << for me >> part - don't get pissed off now. 1st off, a database lacking sub-selects is brain-dead and not worth using. Secondly JDO can only sweep the mess under the rug. Thanks, but no thanks. Third and most important, I really, really don't want to pretend I'm doing EJBQL, JDOQL and what-fucking-ever-QL when the bottom line is this: I have a database, it's name is Oracle, or SQL Server, or DB2 and it does this and that and that's how it does those things and there's this thing called SQL. I don't even *want* independence - but that's how I feel and for the applications I work on. My level of tolerance in the ORM domain as far as abstraction and "independence" does not go above iBATIS' SQL maps.

    Regarding the Joel/C/string copying thing, I do know how to copy strings, what buffer over-runs are and so on, thank you. And yes, the article is about that fact that you have to know the low level - something expresses as a general point in the delicious "programming based on superstition" expression and the doctor metaphor. I hope you see how this relates to the rest of my previous post.

    And now for your enjoyment, as a former C programmer, here's a masterpiece:

    int i;main(){for(;i["]<i;++i){--i;}"];read('-'-'-',i+++"hell\
    o, world!\n",'/'/'/'));}read(j,i,p){write(j/p+p,i---j,i/i);}
  36. 1st off, a database lacking sub-selects is brain-dead and not worth using. Secondly JDO can only sweep the mess under the rug. Thanks, but no thanks.

    That's fine, but not everyone has the choice of what database to use. JDO doesn't sweep the mess under the rug: using some kind of vague attempt at portable SQL would do that. A good JDO product (and other ORMs) will produce optimised SQL for that database - its using the best features of each database, not ignoring the differences.
     
    I don't even *want* independence - but that's how I feel and for the applications I work on.

    That's fine for you, but many of us want and need independence. JDO is a solution that has proven to work well for many companies and developers.
    I do know how to copy strings, what buffer over-runs are and so on, thank you.

    I didn't say you didn't! I was amused that what the article implied should be a 'natural' way to code was so potentially buggy. No disrepect to you.
    And now for your enjoyment, as a former C programmer, here's a masterpiece:int i;main(){for(;i["]<i;++i){--i;}"];read('-'-'-',i+++"hello, world!
    ",'/'/'/'));}read(j,i,p){write(j/p+p,i---j,i/i);}

    Heh.
  37. agnostic == dont know what I am doing[ Go to top ]

    boy, just haven't visited tss for a day an so much happened. :o)
    not all dbs have 'limit' like mysql
    How fucking typical for the born with Java and coolest-framework-of-the-month up it's nose crowd.
    Why should there be a problem in pointing out that mysql has deficiencies? The point that was being made was that JDO (and equivalents) allows independence from this. For example subselects have not been around in mysql until very recently. If you use the equivalent of a subselect in the JDOQL, or some alternative, it will convert this to whatever is necessary in mysql to get the job done (efficiently). The alternative is to have a set of specific SQL strings for mysql that are selected by checking the database vendor and version: messy and almost always unnecessary.

    Thanks Steve, that's what I am trying to say, maybe not so well written. :o)
    Sends me back to that while(*d++=*s++); piece of code and Joel's subsequent remark, so sad but true: I don't care how much you know about continuations and closures and exception handling: if you can't explain why while (*s++ = *t++); copies a string, or if that isn't the most natural thing in the world to you, well, you're programming based on superstition
    I found this discussion from Joel On Software pretty amusing. I have used C for decades and I always assumed that the example he gave was nothing more than an illustration of the low level at which C operates. A C developer must be able to explain why that sort of thing works, but it should hardly be 'natural', and I would be worried working with or employing a developer who said it was: Its actually an example of a potential buffer overrun! A developer should, of course, use strncpy.
  38. agnostic == dont know what I am doing[ Go to top ]

    boy, just haven't visited tss for a day an so much happened. :o)

    Yes, it has been pretty busy!
    Thanks Steve, that's what I am trying to say, maybe not so well written. :o)

    No problem. I am an experienced writer, and glad to be of help :)
  39. I would take that a step further and ask *WHY* are these abstractions ontop of RDBMS's needed at all? Isn't that what JDBC is for?????It amazes me the lengths the Java croud goes to, to avoid having to learn some RDBMS specific SQL. What the hell do you people do, sit there all day and switch your app from one database to another such that you need this rediculous level of abstraction?Why do you need to see your data as objects? A ResultSet is too hard for you to figure out?The Java croud is simply going to bury it self in layer ontop of layer of indirection and abstraction.Mike

    Its very simple. With any large application that needs to access the records in a database, it is very likely that records (or at least certain fields) will be used in more place. The JDBC code to do this is tedious. It makes sense to use a class to represent the record, and place the JDBC code to load and save the data in methods in that class. This is not burying ourselves in abstraction, it's simply avoiding repeated code. If this done with one table, it makes sense to do this with other tables in the database. So, we end up with several classes which represent different tables. In order to avoid repeated code between the classes, we write general-purpose code to load arbitrary classes from tables. To do this we need some kind of mapping between the variables in the classes and the fields in the table. This mapping can be either coded in the classes, or as external data files. So now we have ended up with an object-relational mapping! This is of real benefit: If the tables change, we need only change the code in one place - the relevant class.

    If we want to make things even simpler, we can even cut out most of the SQL! To do this, we use a quality persistence API such as JDO or Hibernate. These systems understand the specifics of a number of databases.

    It's not that we don't understand things such as SQL or ResultSets, it's just that we leave the handling of such things to products and libraries with APIs that do it all for us (sometimes better than we could do it ourselves). It's like networking - Java can handle low-level sockets, but you don't need to use those APIs to write a web service.
  40. ...To do this, we use a quality persistence API such as JDO or Hibernate.

    You have described very well why we need a level of abstraction above JDBC, but that level has a very specific name: ORM.
    If JDO is a new name for ORM then please drop storage agnostic nonsense from the spec and simply say: JDO is ORM and it is supposed to back BMP EB and replace CMP.
    At least that will make some sense (although not much IMO), with the notion of backend independence JDO as spec is doomed ( but API may live).
  41. ...To do this, we use a quality persistence API such as JDO or Hibernate.
    You have described very well why we need a level of abstraction above JDBC, but that level has a very specific name: ORM.If JDO is a new name for ORM then please drop storage agnostic nonsense from the spec and simply say: JDO is ORM and it is supposed to back BMP EB and replace CMP.At least that will make some sense (although not much IMO), with the notion of backend independence JDO as spec is doomed ( but API may live).

    If you abstract far enough away from JDBC to the level of persisting plain objects, and maintaining relationships between the objects (such as persistence by reachability), then why should your application care about whether or not the underlying store is a relational database? There may be a good argument as to why being storage agnostic is nonsense, but I can't see what it is. I would love to be able to use JDO to persist objects in situations lacking relational databases, such as in J2ME applications.
  42. If you abstract far enough away from JDBC to the level of persisting plain objects, and maintaining relationships between the objects (such as persistence by reachability), then why should your application care about whether or not the underlying store is a relational database? There may be a good argument as to why being storage agnostic is nonsense, but I can't see what it is. I would love to be able to use JDO to persist objects in situations lacking relational databases, such as in J2ME applications.
    I would speculate that you want(or need) a decent persistence framework for small non relational storages and see JDO as a savor.
    That is my point: let JDO be such framework and leave RDBMS backed ORMs alone. To get full richness of RDBMS semantic in a framework we have two options: delegate to RDBMS( that is what ORM does) or build RDBMS within the framework to work against flat files or whatever. Hmm, the second approach does not seem suitable for j2me, or does it?
    Well, if you building a RDBM engine then why do not use … RDBMS.
    RDBMS could be small( Hypersonic for example), but small ones lack power of full RDBMSes, even MySQL looks like child play when compared to full power of ORACLE or DB2.
    Do you still believe that JDO could possibly implement full power relational management engine over non-optimized flat files, or bloated XML?
    I would speculate that you want(or need) a decent persistence framework for small non relational storages and see JDO as a savor.
    That is my point: let JDO be such framework and leave RDBMS backed ORMs alone. To get full richness of RDBMS semantic in a framework we have two options: delegate to RDBMS( that is what ORM does) or build RDBMS within the framework to work against flat files or whatever. Hmm, the second approach does not seem suitable for j2me, or does it?
    Well, if you building a RDBM engine then why do not use … RDBMS.
    RDBMS could be small( Hypersonic for example), but small ones lack power of full RDBMSes, even MySQL looks like child play when compared to full power of ORACLE or DB2.
    Do you still believe that JDO could possibly implement full power relational management engine over non-optimized flat files, or bloated XML?
  43. I would speculate that you want(or need) a decent persistence framework for small non relational storages and see JDO as a savor.

    No, my main interest in JDO is as multi-vendor standard for POJO persistence.
    Do you still believe that JDO could possibly implement full power relational management engine over non-optimized flat files, or bloated XML?

    Many features would obviously be absent, but even having a common subset of functionality present would be very useful.

    Remember JDO is not a product it is a specification. An individual vendor does not have to provide flat-file or XML support, and could perhaps concentrate on high-performance relational support. A powerful query language can work perfectly well with flat files and other formats. Obviously such formats do not provide relational integrity or high performance!
  44. powerful queries over flat files[ Go to top ]

    A powerful query language can work perfectly well with flat files and other formats.
    that seems a complete myth to me. If your flat file has no predefined structure (which is the nature of a flat file, otherwise you would call it a csv file or something else), there is no way to do anything else but free-text search, possibly using regular expressions.

    You can only query from structure, and the more primitive the structure is, the more limited will your query facilities be, there is no way around it. Try going to a Manila slum and search somebodys home by street name and house number (havent been to a Manila slum - my assumption is they done have street names and house numbers).

    christian
  45. powerful queries over flat files[ Go to top ]

    A powerful query language can work perfectly well with flat files and other formats.
    that seems a complete myth to me. If your flat file has no predefined structure (which is the nature of a flat file, otherwise you would call it a csv file or something else), there is no way to do anything else but free-text search, possibly using regular expressions.

    It is easy to run JDOQL queries against persistent objects in-memory, so it doesn't matter whether the underlying store can run the query natively or not: JDOQL still works. Of course, the more the underlying store is structured, the more the query engine can take advantage of that structure rather than resorting to in-memory evaluation. So more structure generally equals faster queries. The point, however, is that JDOQL works fine even on things like flat files without indexes. Christian, I hope that addresses your doubts.

    The truth is that many JDO vendors do support non-relational stores. Some offer pre-packaged solutions for XML or ODBMS's or flat files, while others do custom jobs for clients who request JDO support for their specific store. There is obviously a market for non-relational implementations.

    Unless you can point to something concrete in the relational space that JDO doesn't support because of its datastore neutrality, arguing against it is pointless. IMO, JDO 2 has better ORM support than most relational-only products on the market today. So if JDO is able to be datastore-independent while still providing great ORM support, it seems to me that you get the best of both worlds.
  46. powerful queries over flat files[ Go to top ]

    It is easy to run JDOQL queries against persistent objects in-memory, so it doesn't matter whether the underlying store can run the query natively or not: JDOQL still works. Of course, the more the underlying store is structured, the more the query engine can take advantage of that structure rather than resorting to in-memory evaluation. So more structure generally equals faster queries. The point, however, is that JDOQL works fine even on things like flat files without indexes. Christian, I hope that addresses your doubts.
    Are you saying that JDOQL engine will run as efficient as tuned for decades SQL engine?

    Well, from high level of abstraction horse cart and car are equal means of transportation. “Get in” – “sit for a while” – “get out” – done, we have reached our destination. They even have similar API: sits and wheels :)
  47. Are you saying that JDOQL engine will run as efficient as tuned for decades SQL engine?Well, from high level of abstraction horse cart and car are equal means of transportation. “Get in” – “sit for a while” – “get out” – done, we have reached our destination. They even have similar API: sits and wheels :)

    horse carts are more romantic, but it's in cars that you make sex. So, use the same API in different environment and situations.
  48. It is easy to run JDOQL queries against persistent objects in-memory, so it doesn't matter whether the underlying store can run the query natively or not: JDOQL still works.
    How JDO users laod databse to memory, before to run JDOQL query ? As I understand I need to create "persistent objects" in some way, but I can filter stuff at load time without any queries.

    BTW
    AWK very *easy-of-use* and *transparent* to filter flat files, it is very *Object Oriented* too.
  49. powerful queries over flat files[ Go to top ]

    How JDO users laod databse to memory, before to run JDOQL query ?

    They don't. In the case of databases, JDOQL is tranlated into vendor-specfic SQL. Loading data into memory in order to run JDOQL on it is implementation-specific and transparent to the user.
  50. powerful queries over flat files[ Go to top ]

    How JDO users laod databse to memory, before to run JDOQL query ?
    They don't. In the case of databases, JDOQL is tranlated into vendor-specfic SQL. Loading data into memory in order to run JDOQL on it is implementation-specific and transparent to the user.
    As I understand all JDO implementations use JDBC API access RDBMS, any real JDBC driver converts ODBC SQL dialect to vendor-specfic SQL, why do you need to convert it ?
    ODBC and JDBC drivers are implemented for all usefull data stores (I hope Object Database vendors implement JDBC drivers too), so any JDO,ORM,EJB implementation is transparent if it is implemented on top of JDBC. SQL doe's not depend on any data store too, JMS selectors by example use SQL. SQL is object oriented query language, it supports all 8 relational algebra operations.
    Doe's it makes any sence to use JDO specific query language to access data ?
  51. powerful queries over flat files[ Go to top ]

    As I understand all JDO implementations use JDBC API access RDBMS, any real JDBC driver converts ODBC SQL dialect to vendor-specfic SQL, why do you need to convert it ?

    I think you are getting different things mixed up here. There is no SQL dialect conversion with either JDBC or ODBC. JDBC and ODBC are, respectively, Java and C-based APIs which allow connection to databases, and a wide range of functions such as SQL execution and the processing of query results. The SQL dialect you can use depends on the database you are connecting to - it has nothing to do with either JDBC or ODBC.
    Doe's it makes any sence to use JDO specific query language to access data ?

    The point of query languages such as JDLQL and others is to allow portability. If you are using a relational database as the store, the query language is translated to the appriate SQL dialect. The advantage of this is that a vendor can supply a lot of expertise about the particular SQL dialect, along with information about the capabilities of the data store, so highly optimised SQL can be generated.
  52. powerful queries over flat files[ Go to top ]

    I think you are getting different things mixed up here. There is no SQL dialect conversion with either JDBC or ODBC. JDBC and ODBC are, respectively, Java and C-based APIs which allow connection to databases, and a wide range of functions such as SQL execution and the processing of query results. The SQL dialect you can use depends on the database you are connecting to - it has nothing to do with either JDBC or ODBC.

    http://java.sun.com/j2se/1.3/docs/guide/jdbc/spec/jdbc-spec.frame11.html

    You can read this in JDBC specification if you do not trust me.
  53. powerful queries over flat files[ Go to top ]

    I think you are getting different things mixed up here. There is no SQL dialect conversion with either JDBC or ODBC. JDBC and ODBC are, respectively, Java and C-based APIs which allow connection to databases, and a wide range of functions such as SQL execution and the processing of query results. The SQL dialect you can use depends on the database you are connecting to - it has nothing to do with either JDBC or ODBC.
    http://java.sun.com/j2se/1.3/docs/guide/jdbc/spec/jdbc-spec.frame11.htmlYou can read this in JDBC specification if you do not trust me.

    Interesting! I have certainly learned something here. However, this conformance is definitely a subset. For example although the JDBC 3.0 includes support for SQL99, JDBC drivers are not required to support it. A good ORM implementation should translate the query to high-quality SQL that makes best use of the database, and not a subset. Getting the best of different databases with JDBC can require a lot of work for each specific database.
  54. powerful queries over flat files[ Go to top ]

    For example although the JDBC 3.0 includes support for SQL99, JDBC drivers are not required to support it. A good ORM implementation should translate the query to high-quality SQL that makes best use of the database, and not a subset. Getting the best of different databases with JDBC can require a lot of work for each specific database.
    Ok, parse SQL99 and require it in JDO spsecification, it can convert implementation model names to conceptual names too. I will be very glad to use it. Standard API is not very important, It can be many JAVA "persistence" standards, we generate "persistence" code anyway. But common query language is important, I do not think it is a good idea to use AST or to implement SQL on top of EJB and JDO to "abstarct" this political problem.
  55. powerful queries over flat files[ Go to top ]

    For example although the JDBC 3.0 includes support for SQL99, JDBC drivers are not required to support it. A good ORM implementation should translate the query to high-quality SQL that makes best use of the database, and not a subset. Getting the best of different databases with JDBC can require a lot of work for each specific database.
    Ok, parse SQL99 and require it in JDO spsecification, it can convert implementation model names to conceptual names too. I will be very glad to use it. Standard API is not very important, It can be many JAVA "persistence" standards, we generate "persistence" code anyway. But common query language is important, I do not think it is a good idea to use AST or to implement SQL on top of EJB and JDO to "abstarct" this political problem.

    I think that standards for the API are very important. There is no problem in using a range of query languages (or native SQL) in JDO 2.0. Queries can be stored in files externally to the compiled code and easily changed. The code that uses the persistance API can't.
  56. powerful queries over flat files[ Go to top ]

    I think that standards for the API are very important. There is no problem in using a range of query languages (or native SQL) in JDO 2.0. Queries can be stored in files externally to the compiled code and easily changed. The code that uses the persistance API can't.
    Yes, it is a good idea to store queries in external files or in annotations, but I do not think I need to convert anything if it becomes SQL, it is a good query language to use directly. I do not have any reasons to do it, but I can data access code to any programming language automaticaly if it uses standard query language (I do not think better and more portable than SQL exists at this time)
    We use trivial type safe wapper for data access API. There is no meaning to write this code manualy. Probably there some reason for standard API too, it can help to debug generated code or it can make code generators more simple (less templates), but this is not a problem in practice.
  57. powerful queries over flat files[ Go to top ]

    We use trivial type safe wapper for data access API.

    The point of standards is that you don't need to write wrappers. I'm not sure it is that trival anyway.
  58. powerful queries over flat files[ Go to top ]

    We use trivial type safe wapper for data access API.
    The point of standards is that you don't need to write wrappers. I'm not sure it is that trival anyway.
    We need it to wrapp for many reasons anyway, we need to release resources, cast return values, add some stuff for statistics collection or tracing. There are many ways to generate this kind code. I generate JDBC code sometimes too. Probably the best way is to generate JDBC code at this time, but I like to generate code as less as possible.
  59. powerful queries over flat files[ Go to top ]

    It is easy to run JDOQL queries against persistent objects in-memory, so it doesn't matter whether the underlying store can run the query natively or not: JDOQL still works
    java objects have rich structure (although the java object model still lacks some features of the relational model, such as referential integrity and other constraints). To create java objects from flat file data, you must have some (secret) knowledge about the structure of the file that maps to the objects. in that sense its not a flat file anymore. It does not matter whether you run the query in memory or elsewhere, the rpoblem is the same. No model - no query.
    The truth is that many JDO vendors do support non-relational stores
    please, I do not have the time to investigate right now - could you quickly point me to just one vendor that has the same query support for, say, relational DBMS and flat files? Thank you.
    Unless you can point to something concrete in the relational space that JDO doesn't support because of its datastore neutrality, arguing against it is pointless. IMO, JDO 2 has better ORM support than most relational-only products on the market today. So if JDO is able to be datastore-independent while still providing great ORM support, it seems to me that you get the best of both worlds.
    We are in agreement here. If I can get a good JDO-based ORM (and I know I can), I dont care what it does to XML or flat files. However, I think it is dangerous to quote "datastore agnosticism" as a feature, for the simple reason that it does not work in the general case.

    regards,
    christian
  60. powerful queries over flat files[ Go to top ]

    please, I do not have the time to investigate right now - could you quickly point me to just one vendor that has the same query support for, say, relational DBMS and flat files?

    SolarMetric and Xcalia both offer relational JDO implementations as well as support for non-relational stores, including XML and legacy data systems. There are many commercial JDO implementations for ODBMS's. And the JDO reference implementation uses file storage. That's just off of the top of my head; is that enough?

    If you mean "flat files" in the sense of "create objects from these files with arbitrary text content", then of course nothing supports that. But that has absolutely nothing to do with whether support for non-relational stores in general (or file-based stores in particular) is useful. Also, I don't understand your fascination with having one vendor support multiple stores, as opposed to different vendors specializing in different stores. The whole point of a spec is that it allows you to choose between vendors!
  61. powerful queries over flat files[ Go to top ]

    Also, I don't understand your fascination with having one vendor support multiple stores, as opposed to different vendors specializing in different stores. The whole point of a spec is that it allows you to choose between vendors!
    I am not sure what "fascination" you mean. Heres my standpoint: When I hear a vendor make claims about datasore agnosticism, I fear that they dont know their job well with regard to RDBMS, and thats the only datastore I need JDO (or any other ORM) for. I already have all the tools I need for XML and flat files, and I dont care the least bit for a unified API.

    thanks,
    christian
  62. powerful queries over flat files[ Go to top ]

    When I hear a vendor make claims about datasore agnosticism, I fear that they dont know their job well with regard to RDBMS, and thats the only datastore I need JDO (or any other ORM) for. I already have all the tools I need for XML and flat files, and I dont care the least bit for a unified API.thanks,christian

    There is nothing to stop one vendor producing a JDO implementation that has very high quality RDBMS support and another vendor providing, for example, support for XML files. That is the benefit of a JDO being a specification rather than a single-vendor product. You can choose different implementations as appropriate. Just because JDO is datastore agnostic does not mean that individual JDO implementations have support a variety of stores. I know of one JDO product that is targetted primarily at Oracle!

    You may not want a common API that is datastore agnostic but I do, and I'm sure many others do also. I would be disappointed if this aspect of JDO was lost.
  63. powerful queries over flat files[ Go to top ]

    Heres my standpoint: When I hear a vendor make claims about datasore agnosticism, I fear that they dont know their job well with regard to RDBMS, and thats the only datastore I need JDO (or any other ORM) for. I already have all the tools I need for XML and flat files, and I dont care the least bit for a unified API.thanks,christian

    Rather than "fear that they don't know their job", why not check out their implementations and judge them on their merits? You admitted in a previous post that there are very good JDO ORM solutions; why should the fact that the same vendors might also offer non-relational solutions be a point against them? Did you ever consider, for example, that the ability to handle multiple stores is a sign that they have a very well-designed architecture?

    It's perfectly valid that you shouldn't care whether JDO supports non-relational stores. But that *is* a feature of the spec that benefits many users. So long as relational functionality isn't sacrificed, everybody wins.
  64. No need for non-relational JDO[ Go to top ]

    ...with regard to RDBMS, and thats the only datastore I need JDO (or any other ORM) for. I already have all the tools I need for XML and flat files, and I dont care the least bit for a unified API.thanks,christian


    Christian,

    it is absolutely fine if you only need Java object persistence for relational datastores.

    The problem is, that other people have different needs and very much require Java object persistence for non-relational datastores--and there's more out there than RDBMS, XML, and flat files. For example, people in this thread have mentioned legacy datastores before.

    Kind regards,
    Oliver
  65. No need for non-relational JDO[ Go to top ]

    The problem is, that other people have different needs and very much require Java object persistence for non-relational datastores
    Different needs == different tools. Why do you want to pack totally different paradigms into a single API? Switchablity between database types?

    Fredrik Bertilsson
    http://butler.sourceforge.net
  66. No need for non-relational JDO[ Go to top ]

    The problem is, that other people have different needs and very much require Java object persistence for non-relational datastores
    Different needs == different tools. Why do you want to pack totally different paradigms into a single API? Switchablity between database types?Fredrik Bertilssonhttp://butler.sourceforge.net

    You are confusing mechanisms with paradigms. The paradigm is loading and storing objects transparently. The mechanism RDBMs or CSV or filesystems.

    I'm afraid I have no patience with the argument 'different needs = different tools'. Its a meaningless phrase. By that standard, we would have different implementations of java.io for each type of filesystem. We would also not use Java at all, as it is one of the most general-purpose languages ever devised. JDO is in the spirit of Java - multi-purpose and portable.

    JDO is widely used. It can be used for storing to more than just RDBMSes. When used with RDBMSes it can be highly tuned and efficient. If you don't WANT to use its API for more than just RDMBSes, then don't! Nothing is forcing you to. If you don't WANT to take advantage of transparent persistence don't, and you want to explicitly code joins, then do!

    It has the advantage that it is general-purpose, it is a standard, and is multi-vendor. No matter how good the product that you personally are working on, and I'm sure it is good, it fails those tests.
  67. No need for non-relational JDO[ Go to top ]

    By that standard, we would have different implementations of java.io for each type of filesystem. We would also not use Java at all, as it is one of the most general-purpose languages ever devised. JDO is in the spirit of Java - multi-purpose and portable.JDO is widely used. It can be used for storing to more than just RDBMSes
    SQL can work with any "persistent store", it is *transparent* and there are many implementations for all usefull stores, it works with legacy application, report engines, form builders, ... and it will work with future applications without problems too.
    Databse it is not about files and streams. This kind of analogy sounds very silly, this stupid political argument killed JDO, blame yourself.
  68. No need for non-relational JDO[ Go to top ]

    SQL can work with any "persistent store", it is *transparent* and there are many implementations for all usefull stores, it works with legacy application, report engines, form builders, ... and it will work with future applications without problems too. Databse it is not about files and streams. This kind of analogy sounds very silly, this stupid political argument killed JDO, blame yourself.

    There is no such thing as 'SQL'. There are a hundred dialects with different features and different ways of working and vendor extensions. If you want to define a new language that is a superset of all those, go ahead. That is what the query languages in ORMs do. You do realise JDO can use SQL? That is what the query language is translated to where required. That means ORMs work fine with legacy applications and future applications. One of the major uses of ORMs is with legacy applications! There are report engins that work with ORMs. There are form tools that work with ORMs. You may not like ORMs, but you can't criticise it for them failings.

    The transparency we are talking about is nothing to do with the query language. Its about what happens after the query is executed.
    Databse it is not about files and streams. This kind of analogy sounds very silly, this stupid political argument killed JDO, blame yourself.

    It's not silly at all. I chose the analogy specifically because it was relevant: There are different filesystems with different approaches to structure, performance, committing data, security, locking etc.- just like databases. However, we don't java java.io.ext3.File or java.io.nfs.File or java.io.smbfs.File - we abstract the behaviour of a filesystem in a common API.

    This is a technical argument, nothing to do with politics. JDO is not dead, even if this JSR is not passed. It is a JCP specification and will remain so.
  69. Lots of need for non-relational JDO[ Go to top ]

    I have an EJB application in which MessageDriven beans and Session beans, variously fronted by WebServices, manipulate data in a relational database. The performance requirements are exacting to say the least. The data in my database is not used for reporting, and data lives there for only a couple of months.

    The EJBs invoke POJOs containing business logic, and those POJOs manage persistent data which is also POJO-based. Everything is JUnit-testable without a container, and the persistent POJO's are JUnit-testable without a database since they do not know they are persistent.

    With JDO as the persistence infrastructure I have the choice to replace the SQL database with anything that would better meet the system's performance criteria. If I felt it would help, I could run load tests against an object database. Just change two lines in the properties file and restart the application server.

    Whether or not I will ever use a non-SQL backend for this particular application is immaterial - architecturally I have the choice.
  70. No need for non-relational JDO[ Go to top ]

    There is no such thing as 'SQL'.
    Ever heard about ANSI SQL? Most vendors supports a rather large subset of this standard. Just because they have extentions, it does not say thay they don't follow the standard. I work with a rather large enterprise application that supports multiple database vendors. It is possible to use exactly the same SQL statements for all vendors.
    The transparency we are talking about is nothing to do with the query language.
    How can it be? Both SQL and JDOQL rely on relational calculus and indexes (otherwise full table scans has to be performed). JDO does nothing else but takes a subset of the relational model and claim to be "transparent". When JDO is implemented on non-relational databases, relational functionality has to be implemented in the JDO product to enable queries.

    How would you perform the query "customer.city='New York' and order.delivery_date < ?" on a network database?
    There are different filesystems with different approaches to structure, performance, committing data, security, locking etc.- just like databases.
    This is a very good example. In java, the same API are used for both NTFS and POSIX. The result is that all security features are removed, because they are fundamentaly different in different file systems. In this cases some features are sacrified to archive operative system transparancy. Some times it is worth the cost, and sometimes it is not. The differences between file systems are much smaller than the differences between database paradigms.

    Fredrik Bertilsson
    http://butler.sourceforge.net
  71. No need for non-relational JDO[ Go to top ]

    Thanks, Cameron, for your contribution.

    Frederik, if you write an application with ANSI-SQL using JDBC then you can execute the application against any ANSI-compliant database. Your application will work, but by definition it cannot exploit any specific capabilities of a particular database, these "extensions".

    If, however, your application used JDO (or another ORM solution) then the ORM infrastructure is responsible for the SQL not your application. At runtime the ORM infrastructure can issue SQL which is specific to the database in use. So the application developer can get an application whose performance characteristics exploit certain database-specific features, without being locked in to a specific database.

    This is not perculiar to JDO; Hibernate and Toplink probably have equivalent capabilities. JDO additionally caters for the existence of products targeting non-relational backends, but if you don't want that capability don't worry about it.

    Finally there's little point in debating the merits of ORM / "object persistence" / "POJO persistence". The fact that both JDO 1.0+ and EJB 3.0 address exactly that space should suffice to indicate that the space is important to a large sector of the community.

    Kind regards, Robin.
  72. No need for non-relational JDO[ Go to top ]

    We use may JDO extensions too, JDO is useless without evil extensions, but I do not see any problems to regenerate and port this code. I do not understand why are you looking for enemies with this transparence. We need good products like Kodo, not JDO dream.
  73. No need for non-relational JDO[ Go to top ]

    We use may JDO extensions too, JDO is useless without evil extensions, but I do not see any problems to regenerate and port this code. I do not understand why are you looking for enemies with this transparence. We need good products like Kodo, not JDO dream.

    I agree that JDO 1.0 was limited in many respects (although that is a very long way from 'useless'). One of the reasons for JDO 2.0 was to remove many of these limitations and to standardise features that had previously been added as extensions, so anyone who uses JDO can be confident they are using a good product (like Kodo). Many of the features present in 'evil extensions' are in the JDO 2.0 draft.
  74. powerful queries over flat files[ Go to top ]

    To create java objects from flat file data, you must have some (secret) knowledge about the structure of the file that maps to the objects. in that sense its not a flat file anymore.

    In the mainframe world, a flat file is an extract of a RDBMS, Hierchial, VSAM and ... datastore. The format is know to those who create the file and who will use the file (or one can look in working storage). It is usually fixed field but can be comma or other character delimited. A file that has "random" text is just a text file or file. I just walked to the cube next to me and asked the person, who is mainframe programmer, what a "flat file" meant to her. She confirmed this.
  75. If you abstract far enough away from JDBC to the level of persisting plain objects, and maintaining relationships between the objects (such as persistence by reachability), then why should your application care about whether or not the underlying store is a relational database?
    If you want a query mechanism, you have to decide what database paradigm you want to use. Queries in hierarchial and relational databases are very different and can't be merged in a single language. JDOQL is such a direct ripp-off from SQL, and it is understandable that RDBMS are used as backends.
    I would love to be able to use JDO to persist objects in situations lacking relational databases, such as in J2ME applications.
    There are relational databases with a very small footprint, like hsqldb. Hsqldb is used in J2ME applications. There are also JDBC-drivers that emulates relational databases using flat files.

    Fredrik Bertilsson
    http://butler.sourceforge.net
  76. If you want a query mechanism, you have to decide what database paradigm you want to use. Queries in hierarchial and relational databases are very different and can't be merged in a single language.


    Odd. 9 years ago I worked for a VERY large company that does consulting and contracting for big name companies. We used a single mechanism to access both IMS and DB2 from within the application logic. It can be done.
  77. agnostic == dont know what I am doing[ Go to top ]

    If you want a query mechanism, you have to decide what database paradigm you want to use. Queries in hierarchial and relational databases are very different and can't be merged in a single language.
    Odd. 9 years ago I worked for a VERY large company that does consulting and contracting for big name companies. We used a single mechanism to access both IMS and DB2 from within the application logic. It can be done.

    ........

    http://publib.boulder.ibm.com/infocenter/dzichelp/index.jsp?topic=/com.ibm.ims9.doc.jgr/ie0j1sql1000622.htm
  78. Yes, there are many examples of SQL drivers for non-relational datastores. These drivers acts as relational databases. You doesn't need a full-featured RDBMS if you want a relational database.

    When you put a SQL (relational) interface on top of hierachial or network databases, you will also loose some of the features in these paradigms.

    Fredrik Bertilsson
    http://butler.sourceforge.net
  79. Yes, there are many examples of SQL drivers for non-relational datastores. These drivers acts as relational databases. You doesn't need a full-featured RDBMS if you want a relational database. When you put a SQL (relational) interface on top of hierachial or network databases, you will also loose some of the features in these paradigms.Fredrik Bertilssonhttp://butler.sourceforge.net

    So they can be merged into one language (which may or may not be optimal)?
  80. Its very simple. With any large application that needs to access the records in a database, it is very likely that records (or at least certain fields) will be used in more place. The JDBC code to do this is tedious.

    Bullshit. You can make a method that returns a ResultSet and call that method from multiple places. You don't need a damn 'persistence solution' to do that.
      It makes sense to use a class to represent the record, and place the JDBC code to load and save the data in methods in that class. This is not burying ourselves in abstraction, it's simply avoiding repeated code.

    I don't get what you are saying here...how is putting the data into a class 'better' than a resultset?

    String x = myObj.getMyField();

    or

    String x = rs.getString("MyField");

    What's the difference?

    At least with ResultSet I can easily query the metadata, with an object you have to resort to some ugly reflection hack.
    If this done with one table, it makes sense to do this with other tables in the database. So, we end up with several classes which represent different tables. In order to avoid repeated code between the classes, we write general-purpose code to load arbitrary classes from tables. To do this we need some kind of mapping between the variables in the classes and the fields in the table.

    A class for each table huh? Code bloat. These mapping files are the mother of all evil and just another thing to get throughly screwed up. Trust me, after going from a large JDBC based project to a Toplink project, the JDBC project was *FAR* simpler and less error prone because there is simply less crap to go wrong. Oh, and toplink generated about 20x the number of queries as the JDBC version...and also required us to 'cluster' our application servers to handle the 'distributed cache synchronization' bs. Never mind the fact that the database is *ALREADY* clustered and has a much *BIGGER* cache built into it than all of the app servers combind. This is madness.
    This mapping can be either coded in the classes, or as external data files. So now we have ended up with an object-relational mapping! This is of real benefit: If the tables change, we need only change the code in one place - the relevant class. If we want to make things even simpler, we can even cut out most of the SQL! To do this, we use a quality persistence API such as JDO or Hibernate. These systems understand the specifics of a number of databases.It's not that we don't understand things such as SQL or ResultSets, it's just that we leave the handling of such things to products and libraries with APIs that do it all for us (sometimes better than we could do it ourselves). It's like networking - Java can handle low-level sockets, but you don't need to use those APIs to write a web service.

    Yes, it might be able to do it better than you, but my expeiences with ORM is that they do it WORSE. Hell, just look at the toplink and hibernate forums. People who 'bought' into ORM end up having to go back to JDBC to get their app to do what they want.

    Repeat after me. JDBC is *NOT* a low level API. It is a simple, high level API for interacting with a RDBMS. I can teach your average Java guy how to do selects, inserts, updates, deletes, all within about an hour with JDBC. Try explaining the intracasies of the XML mapping, reflective invocation of POJO's, ORM apis, distributed cache synchronization, etc. to someone in an hour. Good luck. An ORM based project will be more complex (at many levels) than the same project with intelligently written JDBC.

    If you have a lot of repeated JDBC code, that is not the fault of JDBC, you just need to refactor your code.

    After living through one ORM project I can tell you that it is academic bullcrap designed by some computer science majors with too much time on their hands.
  81. Its very simple. With any large application that needs to access the records in a database, it is very likely that records (or at least certain fields) will be used in more place. The JDBC code to do this is tedious.
    Bullshit. You can make a method that returns a ResultSet and call that method from multiple places. You don't need a damn 'persistence solution' to do that.

    It's not getting the ResultSet, its what you do with the contents. With ResultSets you explicitly fetch named fields from a database. This can lead to major problems if the database structure changes. How do you determine where a field is used? Suppose the type of a field changes in the database. The effects are only detectable at run time. With an ORM, changes in database structure (resulting in changes in object structures and field types) are detectable at compile time - a far safer situation. Extensive use of JDBC also makes for bad code structure as there is usually little separation between business logic (what you do with the data) and database logic (how you accessed it). You may not find this objectionable, but many would consider it bad practise.

     
    It makes sense to use a class to represent the record, and place the JDBC code to load and save the data in methods in that class. This is not burying ourselves in abstraction, it's simply avoiding repeated code.
    I don't get what you are saying here...how is putting the data into a class 'better' than a resultset?
    String x = myObj.getMyField();or String x = rs.getString("MyField");What's the difference?

    Firstly, there is a lot of fussy JDBC code that has to come before or after such data accesses. There is the closing of resultsets and statements, the next() calls to see if there is more data etc. This can be avoided using JDO (and similar APIs). With transparent persistence APIs such as Hibernate and JDO, there is absolutely no coding required to store altered values.
    At least with ResultSet I can easily query the metadata, with an object you have to resort to some ugly reflection hack.

    I can't see why a few method calls to do reflection (which are in any case hidden with the persistence API) are any more or less ugly than calling metadata query methods.
    If this done with one table, it makes sense to do this with other tables in the database. So, we end up with several classes which represent different tables. In order to avoid repeated code between the classes, we write general-purpose code to load arbitrary classes from tables. To do this we need some kind of mapping between the variables in the classes and the fields in the table.
    A class for each table huh? Code bloat. These mapping files are the mother of all evil and just another thing to get throughly screwed up.

    Mapping classes/structures to the results of queries is nothing new - I was doing it with C and Btrieve 20 years ago! Also, I was simplifying. With a good API (Hibernate and JDO 2.0, for example) there is no need to do this - results of queries can be returned as arrays of values if required.
    Oh, and toplink generated about 20x the number of queries as the JDBC version...and also required us to 'cluster' our application servers to handle the 'distributed cache synchronization' bs. Never mind the fact that the database is *ALREADY* clustered and has a much *BIGGER* cache built into it than all of the app servers combind. This is madness.

    I can't discuss Toplink, as I have never used it. I can say that no such query bloat or clustering was imposed by the JDO implementation I used (JDOGenie/Versant). It was very clean.
    This mapping can be either coded in the classes, or as external data files. So now we have ended up with an object-relational mapping! This is of real benefit: If the tables change, we need only change the code in one place - the relevant class. If we want to make things even simpler, we can even cut out most of the SQL! To do this, we use a quality persistence API such as JDO or Hibernate. These systems understand the specifics of a number of databases.It's not that we don't understand things such as SQL or ResultSets, it's just that we leave the handling of such things to products and libraries with APIs that do it all for us (sometimes better than we could do it ourselves). It's like networking - Java can handle low-level sockets, but you don't need to use those APIs to write a web service.
    Yes, it might be able to do it better than you, but my expeiences with ORM is that they do it WORSE. Hell, just look at the toplink and hibernate forums. People who 'bought' into ORM end up having to go back to JDBC to get their app to do what they want.Repeat after me. JDBC is *NOT* a low level API. It is a simple, high level API for interacting with a RDBMS.

    I would consider an API to be lower level if it required more statements to do the same amount of work than an alternative. By this measure, JDBC is most certainly lower level, as it is hugely more verbose than JDO and the alternatives. I don't see why I should have to explicitly code individual field accesses from ResultSets when data is retrieved transparently on-demand when I call accessor methods on my JDO objects. My code size is reduced phenomenally compared with the JDBC alternative. My understanding is that people who have to go back to JDBC do so because they aren't using the right approach with the ORM, such as coding large numbers of queries rather than using retrieval and persistence by reachability.
    I can teach your average Java guy how to do selects, inserts, updates, deletes, all within about an hour with JDBC. Try explaining the intracasies of the XML mapping, reflective invocation of POJO's, ORM apis, distributed cache synchronization, etc. to someone in an hour. Good luck. An ORM based project will be more complex (at many levels) than the same project with intelligently written JDBC.

    If you are getting involved in the details of XML mapping and relection, I would suggest you are using a very poor ORM tool. I use simple GUI tools to manage my JDO configuration files and I have never once had to consider reflection.
    If you have a lot of repeated JDBC code, that is not the fault of JDBC, you just need to refactor your code.After living through one ORM project I can tell you that it is academic bullcrap designed by some computer science majors with too much time on their hands.

    Perhaps it is, but it is very widely used bullcrap that seems to make development easier for a huge number of developers.

    I remember exactly the same kinds of arguments being used against object-orientation decades ago!
  82. agnostic == dont know what I am doing[ Go to top ]

    I remember exactly the same kinds of arguments being used against object-orientation decades ago!
    He probably doesn't like AOP either. Having strings all over the place instead of accessors makes AOP a little more difficult.

    Having strings all over the place instead of accessors also makes searching more difficult. If you scatter JDBC getString() all over the place you have to do a string search vs a find references.

    As for bloat and clustering - I would say the problem is the Web App paradigm not the OO paradigm.

    Mark
    These are my personal views. Feel free to disagree.
  83. This can lead to major problems if the database structure changes.
    If you change your database structure, it will affect your application, otherwise you would not change the database structure. Lets say you add a column, telephonenumber. You will probably change your application all the way to the client to be able to show and edit the telephonenumer. Why would you add it if you should not use it?
    Extensive use of JDBC also makes for bad code structure as there is usually little separation between business logic (what you do with the data) and database logic (how you accessed it)
    A lot of business logic is implemented in the database schema. It is not possible to define the difference between "business" logic and "database" logic.
    Firstly, there is a lot of fussy JDBC code that has to come before or after such data accesses.
    Agree, we need a more high-level API on to of JDBC to access relational databases. Unfortunately the O/R mappers of today is not the solution.

    Fredrik Bertilsson
    http://butler.sourceforge.net
  84. If you change your database structure, it will affect your application, otherwise you would not change the database structure. Lets say you add a column, telephonenumber. You will probably change your application all the way to the client to be able to show and edit the telephonenumer. Why would you add it if you should not use it?

    True, but with object-relational mapping, the implications of such changes can be determined by compilation. If you change the structure of a database, there are tools that will change the structure of the classes that represent that database, and a compilation will show where these changes have effects.
    A lot of business logic is implemented in the database schema. It is not possible to define the difference between "business" logic and "database" logic.

    No. The schema defines the data structure, not the logic of how it is processed. With an ORM the mechanics of database access can be largely hidden. I can (for example) get a customer record from the database, as an object. I can then access an invoice associated with that customer with a simple accessor method:

    customer.getInvoice();

    I can update properties of the customer, the invoice or any associated objects, all using pure Java code, with no JDBC and no database-specific SQL. A single 'commit()' method call to the ORM ensures that any modifications I make are stored.
    Agree, we need a more high-level API on to of JDBC to access relational databases. Unfortunately the O/R mappers of today is not the solution

    Well, a huge number of Java developers who are productively using O/R mappers will fundamentally disagree with you.
  85. No. The schema defines the data structure, not the logic of how it is processed.
    If you define a foreign key you tell the database: "Don't allow anyone to put an unvalid value in these columns." I think that can be considered as processing logic. If you are using a database that doesn't support foreign keys, that logic would reside inside the "business" layer. Queries are also a good example of processing logic that also would be put inside the "business" layer if the database doesn't support them. When relational databases was introduced, a lot of logic was moved from the "business" layer to the database layer.
    I can then access an invoice associated with that customer with a simple accessor method:
    customer.getInvoice();
    Actually, you don't need a O/R mapper to do this. If customer and invoice are two tables related with a foreign key, a relational framework (and generator) could produce this only by reading meta-data from the database.
    A single 'commit()' method call to the ORM ensures that any modifications I make are stored.
    Transaction handling has absolutely nothing to do this O/R mapping. There are plenty of other ways to do this.
    Agree, we need a more high-level API on to of JDBC to access relational databases. Unfortunately the O/R mappers of today is not the solution
    Well, a huge number of Java developers who are productively using O/R mappers will fundamentally disagree with you.
    Using a O/R mapper is more productively than using JDBC in most cases. But I think that complex O/R mapping (other than 1:1 between table and class) disables you to use some of the features in a relational database and it forces the programmer to do unnecessary mapping configuration.

    Fredrik Bertilsson
    http://butler.sourceforge.net
  86. When relational databases was introduced, a lot of logic was moved from the "business" layer to the database layer.

    Personally, I would still not condider this 'logic'. But I see your point.
    I can then access an invoice associated with that customer with a simple accessor method:customer.getInvoice();
    Actually, you don't need a O/R mapper to do this. If customer and invoice are two tables related with a foreign key, a relational framework (and generator) could produce this only by reading meta-data from the database.

    You need an O/R mapper to allow such data to be transparently accessed using pure clean Java code, which was my point.
    A single 'commit()' method call to the ORM ensures that any modifications I make are stored.
    Transaction handling has absolutely nothing to do this O/R mapping. There are plenty of other ways to do this.

    I was not saying that Transaction handling did have anything to do with O/R mapping specifically. The relevant point is that a single method call is all that is needed to ensure that all relevant changes to objects are stored.
    Agree, we need a more high-level API on to of JDBC to access relational databases. Unfortunately the O/R mappers of today is not the solution
    Well, a huge number of Java developers who are productively using O/R mappers will fundamentally disagree with you.
    Using a O/R mapper is more productively than using JDBC in most cases. But I think that complex O/R mapping (other than 1:1 between table and class) disables you to use some of the features in a relational database and it forces the programmer to do unnecessary mapping configuration.Fredrik Bertilssonhttp://butler.sourceforge.net

    I'm not sure what you are saying here - do you have an example?
  87. <blockqoute>
    You need an O/R mapper to allow such data to be transparently accessed using pure clean Java code, which was my point.In your example, customer and invoice, the only O/R mapping done is the simpliest possible, one class for one table. So I agree that you need O/R mapping, but not the complex one that tools like Hibernate provide.

    <blockqoute>
    I'm not sure what you are saying here - do you have an example?Yes, look at http://butler.sourceforge.net. You will be able to create applications using this framework with much less effort than Hibernate.

    /Fredrik
  88. http://butler.sourceforge.net>. You will be able to create applications using this framework with much less effort than Hibernate. /Fredrik
    Do you think grapihical editor for ER modeling can be usefull for this code generator ? I can help to impelment it, I have time for experiments on weekends and it must be intersting.
  89. I can help to impelment it
    You are welcome to join the bulter project. You can find me (frebe) at sourceforge. http://bulter.sourceforge.net or http://sourceforge.net/projects/butler.

    Fredrik Bertilsson
  90. I'm not sure what you are saying here - do you have an example?
    Yes, look at http://butler.sourceforge.net. You will be able to create applications using this framework with much less effort than Hibernate. /Fredrik

    This is not transparent. Have a look at Hibernate or the JDO spec to see what transparent persistence means. I don't want to have to manipulate rcecords. I don't want to have to call a 'getRelatedRecords' method. This is not separating the mechanics of database access from the business logic. Also, the JDO product I use has a very good graphical O/R Mapping tool. Finally, JDO is a multi-vendor standard I can go to an alternative supplier if there is a problem with the product I am using.
  91. This is not transparent....I don't want to have to manipulate rcecords
    You are not manupilating records, you are manupilating objects. The name of the class ends with "Record", but it is still a class.

    What do you mean with transparent? Independence of database paradigm? In that case, Butler is not transparent.
    I don't want to have to call a 'getRelatedRecords' method.
    If you are using the generator, you will have navigation methods generated. Lets say you have two tables: customer and invoice, with a one-to-many relation between them. Then you will have customer.getInvoices() and invoice.getCustomer() generated.

    With JDO I see two main problem. First, the query language is coded as strings in java. If you want to manipulate a query (changing sort order, or adding paging conditions), you need to parse the query. It would be better to have the query as an object. Second the concept of joins is not supported in the same clean way as a relational database does. Joins are very important in queries, because you can decide if you want to load related records at the first search, or if you want to use lazy-loading.
    JDO is a multi-vendor standard
    SQL is also a multi-vendors standards with a lot more vendors than JDO. And it is not programming-language specific. How do you think JDOQL ever could replace SQL if it only can be used in a java-environment?

    Fredrik Bertilsson
    http://butler.sourceforge.net
  92. With JDO I see two main problem. First, the query language is coded as strings in java. If you want to manipulate a query (changing sort order, or adding paging conditions), you need to parse the query. It would be better to have the query as an object.

    JDO queries *are* objects. To change the sort order or paging, you can call Query.setOrdering() and Query.setRange(). JDOQL can be written as a single string that includes the ordering, range, etc, but it doesn't have to be. The JDO Query API breaks things down into a filter, result, grouping, ordering, and range.
    Second the concept of joins is not supported in the same clean way as a relational database does. Joins are very important in queries, because you can decide if you want to load related records at the first search, or if you want to use lazy-loading.

    Joins are transparent in JDO. You can navigate object relations in the query filter or result clause, and the joins are made for you. Eager fetching is controlled through the query result clause and/or the FetchPlan interface, which allows you to specify exactly what fields and relations (including recursive fields and relations) you want to retrieve. I don't know how you can get much cleaner than that. Of course, JDO also supports SQL queries for implementations that use relational stores.
  93. agnostic == dont know what I am doing[ Go to top ]

    Joins are transparent in JDO. You can navigate object relations in the query filter or result clause, and the joins are made for you. Eager fetching is controlled through the query result clause and/or the FetchPlan interface, which allows you to specify exactly what fields and relations (including recursive fields and relations) you want to retrieve. I don't know how you can get much cleaner than that. Of course, JDO also supports SQL queries for implementations that use relational stores.
    There are many things I like in JDO and I think SQL support was a step to the right direction, but as I understand I will have no cool features you are talking about if I will use SQL with JDO. I think this polical transparence was a big mistake, there are better politicans in EJB side. It must be better promote stuff like this using more technical and pragmatic motivation.
  94. JDO queries *are* objects.
    Yes, the query is an object (interface), but the filter is just a string.
    To change the sort order or paging, you can call Query.setOrdering()
    I also need the manipulate the filter to enable paging. The filter a string that need to be parsed. The argument to setOrdering is also a string. This makes it possible to misspell column names and you would not detect the mistake until runtime. It will also disable you to use code-completion in the IDE.

    Let me show you one example of how a query API should look like. Lets say we have two tables, customer and order. I want to find all customers and their orders that are from Atlanta.

    query = customer.createQuery()
    query.setFilter(new Eq(customer.city(), "Atlanta"));
    query.join(order);
    list = query.run()

    In this case you have a manipulatable and type-safe query object.
    Joins are transparent in JDO.
    I like transparent joins too, but the issue of joins are an important performance issue. I think it is wise to make it possible to define in the query what tables to join or not. In the example above you can retrieve order objects by calling customer.getOrders(). Depending on the original query joined orders or not, a new query will implicit be called to fetch the related join objects. This is very easy to implement in a relational oriented database framework.

    Fredrik Bertilsson
    http://butler.sourceforge.net
  95. The filter a string that need to be parsed. The argument to setOrdering is also a string. This makes it possible to misspell column names and you would not detect the mistake until runtime.

    This is a good point, but the way that a transparent persistence API like JDO should be used means that the amount of use of query strings should be kept to a minimum.
    Joins are transparent in JDO.
    I like transparent joins too, but the issue of joins are an important performance issue. I think it is wise to make it possible to define in the query what tables to join or not.

    If you get a good ORM implementation you can, of course. With the JDO product I use this can be specified in the metadata.

    There are many high quality JDO products. Why not download a free version such as JPOX or some trial or evaluation version of a commercial product such as Versant OpenAccess, and actually have a look at what they offer. You will find most if not all the tuning and performance features you are after, but you get the advantages of using a multi-vendor standard with clean transparent persistence and loading.
  96. the way that a transparent persistence API like JDO should be used means that the amount of use of query strings should be kept to a minimum.
    This is the problem with "transparent" persistence. The use of queries is limited. Why sacrifice such a good feature just because you want transparent persitence.

    And I see no reson to have a "transparent" persistence. Since computer science was born, there have been three main database paradigms: Hierarchial, network and relational. The last 20 years, the relational paradigm has been used almost all new applications (except of some applications that uses OO (network) databases). Currently there are no new database paradigm that can replace relational databases. There will be in the future, but today we have no idea how this paradigm would look like. It is possible to make an application transparent to existing paradigms, but I doubt that it will possible to just plug in databases of the next generation in old applications, even if they are "transparent".

    Fredrik Bertilsson
    http://butler.sourceforge.net
  97. the way that a transparent persistence API like JDO should be used means that the amount of use of query strings should be kept to a minimum.
    This is the problem with "transparent" persistence. The use of queries is limited.

    No. The point is that the use of queries CAN be limited. It doesn't mean you HAVE to limit them. Its an option, not a requirement.
    And I see no reson to have a "transparent" persistence.

    The reason is that it leads to better and more maintainable code. It cuts out 'boilerplate' code that is irrelevant to the processing logic. For example, if I am doing a financial calculation, perhaps iterating through a list customers, and fetching assciated invoices, I want to express that in clean Java code that relevant to the calculation. Unless I am doing a calculation for a music shop, I don't want to have to use the term 'record'! When I am doing the calculation, I want to deal with amounts, sums and payments, not fields, columns and tables.

    It's simply good software practice.
    I doubt that it will possible to just plug in databases of the next generation in old applications

    The mechanisms of transparent persistence are generally applicable. Transparent persistence is done either by enhancement of classes (making class implement an Interface, either in source code or by bytecode enhancement) or by proxying the class and intercepting methods. These aren't techniques specific to transparent persistence, they are general techniques that allow wrapper code to be placed around methods, and have been around in various languages for decades. They can be used for any situation in which the underlying processes are to be hidden, so will work for future storage mechanisms.
  98. For example, if I am doing a financial calculation, perhaps iterating through a list customers, and fetching assciated invoices, I want to express that in clean Java code that relevant to the calculation.
    In what way is this related to transparent persistence? A seamleass interface to relational databases is very easy to do.
    I don't want to have to use the term 'record'
    It is just a name of a class. A relational framwork does not need to use the term 'record'. If we use the term 'PersistentObject', would you feel better?

    I ask you why you must have a transparent persistence framework. Your answer is: I don't want to use the term record. Can you please give me a better answer.
    When I am doing the calculation, I want to deal with amounts, sums and payments, not fields, columns and tables.
    The only thing you have to do is to generate classes based on the table structure. Lets say we have a table order with the columns orderid, partno, quantity, amount. Then you could have a generated class like this

    class Order
      int getOrderid()
      void setOrderid(int)
      float getQuantity()
      void setQuantity(float)
      float getAmount()
      void setAmount(float)

    What is the problem with a class like this?
    The mechanisms of transparent persistence are generally applicable
    No they are not. Imagine life before relational databases existed. Query expressions like "delivery_date > ?" was not used to fetch records. Instead predefined indexes was used for retrival. If JDO would have been created at that time, it would not have had a Query interface with a filter as string expression. Because that kind of queries did not exists, how could the creators of the API imagine what some day relational databases would come and give you a possibility to query records in that way? Neither can we now tell how the next generation of databases will look like.

    Talkning about "persistence" is also misleading. A relational database does a lot more than persist data. Even if you don't have any persistence needs (server that never needs to reboot and 100% failsafe powersupply), you would still need a relational database in many situations. Features like queries, transactions, locking, etc has nothing to do with persistence. Wrapping a relational database inside a "persistence" will disable you to use some of the features.

    Fredrik Bertilsson
    http://butler.sourceforge.net
  99. What is Transparent Persistence?[ Go to top ]

    JDO implements Transparent Persistence for Java objects. For reference, something which seems to have been overlooked by many posters, JSR-220 aims to do much the same thing. There are degrees of transparence, but the fundamental aim very similar in both specs.

    * The Java object model design does not have to be constrained by persistence considerations. Feel free to use inheritance, sets, collections, maps, bi-directional and uni-directional relationships, etc.

    * The Java types are are translated into the underlying type system of the backend database.

    * Nativgation of a relationship in the persistent Java object model causes related objects to be loaded into memory if not already loaded.

    * Persistent objects which are changed are automatically flushed to the database on commit. (In JDO objects inherently know they are dirty.)

    * Persistence-capable objects which become reachable from persistent objects are inserted into the database on commit. (I suggested this be made switchable on a per-relationship basis but I can't recall if that's been done.)

    * The query language allows queries to be expressed in terms of domain model artefacts (objects, fields, associations) so that queries are as datastore-independent as the rest of the architecture. The result of a query is (usually) an Object, not merely primitive field values.

    The above points represent "Transparrent Persistence".
  100. What is Transparent Persistence?[ Go to top ]

    Datastore independence is not a specific element of trasparent persistence, which refers instead to the Java object model as in "transperent to the Java object model". However an architecture such as JDO's, in which the application and all queries are expressed in object model terms, lends itself to datastore independence if the specification is evolved with this in mind.
  101. For example, if I am doing a financial calculation, perhaps iterating through a list customers, and fetching assciated invoices, I want to express that in clean Java code that relevant to the calculation.
    In what way is this related to transparent persistence? A seamleass interface to relational databases is very easy to do.

    Transparent persistence not nothing to do with a seamless interface. Its to do with not having to use an interface at al, once you have run a query to retrieve an object. Why not look it up before you comment further. Have a look at the Hibernate website, or the JDO spec.
    I don't want to have to use the term 'record'
    It is just a name of a class. A relational framwork does not need to use the term 'record'. If we use the term 'PersistentObject', would you feel better?
    Of course not. Why should my calculation code have to mention persistence at all? What does 'PersistentObject' have to do with an Account, an Invoice or a Customer, if I am doing finance calculation?
    When I am doing the calculation, I want to deal with amounts, sums and payments, not fields, columns and tables.
    The only thing you have to do is to generate classes based on the table structure. Lets say we have a table order with the columns orderid, partno, quantity, amount. Then you could have a generated class like thisclass Order&nbsp;&nbsp;int getOrderid()&nbsp;&nbsp;void setOrderid(int)&nbsp;&nbsp;float getQuantity()&nbsp;&nbsp;void setQuantity(float)&nbsp;&nbsp;float getAmount()&nbsp;&nbsp;void setAmount(float)What is the problem with a class like this?

    Nothing, assuming the class, and none of the methods in it, have to know anything about persistence.
    The mechanisms of transparent persistence are generally applicable
    No they are not. Imagine life before relational databases existed. Query expressions like "delivery_date > ?" was not used to fetch records. Instead predefined indexes was used for retrival. If JDO would have been created at that time, it would not have had a Query interface with a filter as string expression. Because that kind of queries did not exists, how could the creators of the API imagine what some day relational databases would come and give you a possibility to query records in that way? Neither can we now tell how the next generation of databases will look like.Talkning about "persistence" is also misleading.

    Again, 'transparent persistence' is being confused with 'query'. I believe JDO 2.0 has the ability to use diffent query mechanisms. The JDO product I use certainly does. This means that JDO is definitely suited to future databases as a new query language can be plugged in, even with existing code.
     
    A relational database does a lot more than persist data. Even if you don't have any persistence needs (server that never needs to reboot and 100% failsafe powersupply), you would still need a relational database in many situations. Features like queries, transactions, locking, etc has nothing to do with persistence. Wrapping a relational database inside a "persistence" will disable you to use some of the features.Fredrik Bertilssonhttp://butler.sourceforge.net

    I think, before you say any more, you should actually have a look at an implementation of JDO or some other ORM. You seem to be assuming that using an ORM somehow restricts what you can do. This is nonsense. These products provide full transaction and locking support. If they did not, they would not be used by large companies for key applications. The point about JDO is that you can, of course, use large relational databases, and virtually all the features of those databases.... but you don't have to.
  102. Queries in JDO[ Go to top ]

    JDO defines its own query language, JDOQL, in which queries are expressed in terms of the Java object model.

    There are two ways to represent a JDOQL Query; as an object, with property get/set methods for each clause of the query, or as a single string beginning with the word "SELECT..." but still referencing only Java domain object artefacts.

    The PersistenceManager interface exposes methods to create Query instances. Some of these methods allow an optional query language to be specified (JDOQL is the default). Thus you can write SQL queries if you wish, and JDO will pass them through to the database unaltered. However your application becomes SQL-dependent and Schema-dependent if you do this, so use it as a last resort.

    Queries can be written in your code or externalized to an XML-based metadata file. Named queries in metadata can be changed without code impact (perhaps to exploit a different query language!) as long as the query semantics remain unchanged.

    I hope that helps clarify things a little.

    Kind regards, Robin.
  103. The only thing you have to do is to generate classes based on the table structure. Lets say we have a table order with the columns orderid, partno, quantity, amount. Then you could have a generated class like this

    class Order
      int getOrderid()
      void setOrderid(int)
      float getQuantity()
      void setQuantity(float)
      float getAmount()
      void setAmount(float)

    What is the problem with a class like this?

    Frederik, you know what the problem is.

    1) The functionality that you provide is a direct 1:1 mapping (since you gen'd the "records"), which JDO and Hibernate also support. What you don't provide is any other form of mapping.

    2) The functionality that you provide is done so by generating the classes. In other words, the developer cannot use their own POJOs. As a result, all of the weaknesses of code generation are inherited by using your approach.

    3) Since your model is more similar to JDO than Hibernate (it appears from the code that you maintain lists of changed objects instead of checking them en masse before committing the transaction) what you've basically done is generate PersistenceCapable implementations instead of decorating POJOs at runtime. (JDO supports both.)

    In the end, I'm a little surprised that you don't either implement the standard JDO interfaces or at least admit the similarities in approaches and explain the benefits for certain projects of "doing it your way". I fully respect the "doing it your way" approach (a.k.a. the "screw the standard JDO interfaces" approach), as long as you explain under what conditions your solution is better. If I understood why "your way" was better, I could even recommend the use of your framework to people when I saw those particular situations.

    Otherwise, I just have to assume that you are disparaging a proven solution (JDO) because you didn't think to implement the JDO interfaces, and you don't want all your work to be "wasted".
    The mechanisms of transparent persistence are generally applicable

    No they are not.

    Again, not to be a bore, but your Butler framework (assuming that I can understand the code) is largely designed to support the same "transparent persistence" model that JDO and Hibernate support. So if you don't like "transparent persistence", why do you keep track of which fields are "set" on your records? You do it to be able to persist those back to the database. That's a big part of "transparent persistence". You keep lists of records that have changed, to be able to persist those back to the database. That's a big part of "transparent persistence".
    Imagine life before relational databases existed.

    Imagine life before computers existed ;-)
    Neither can we now tell how the next generation of databases will look like.

    Yup, you're right. We certainly shouldn't try to build specs for problems that we can't imagine.

    OTOH, I think Steve has a pretty good idea already of what he thinks the next generation of "databases" will be ;-)
    Talkning about "persistence" is also misleading. A relational database does a lot more than persist data. Even if you don't have any persistence needs (server that never needs to reboot and 100% failsafe powersupply), you would still need a relational database in many situations. Features like queries, transactions, locking, etc has nothing to do with persistence. Wrapping a relational database inside a "persistence" will disable you to use some of the features.

    Actually, it's quite fair to talk about persistence. What a database does really, really well is to not lose that data. That's persistence. Some of our customers are using databases that have "morphed" (but not been replaced) for almost forty years. That's pretty friggin' persistent.

    Secondly, regarding transactions, no kidding! That's the beauty of the database, that it does those. In fact, the transaction is one of the things that makes doing the transparent persistence possible at all! And by the way, what is a database? It's the outermost transaction of a nested transactional system that happens to never commit. (Think about it for a while. ;-)

    Queries? You bet! Your solution, JDO, Hibernate, iBatis, etc. .. they all totally depend on those queries!

    Your argument is that by abstracting something, you lose something. I agree -- in fact I can see with your Butler project that you automatically lose most of the advanced query power of the various databases, since you've hard-coded the possible query operators, and you don't include a lot of the features that (for example) Oracle supports. (You should have listened to Juozas and just taken a SQL string ;-)

    To be honest, though, you accepted a trade-off that engineers have been accepting in software for ages -- that to simplify the next guy's job (in your case, that's the app developer) you have to insulate them from the chaos below. To wit, you don't hear Java developers complaining that they don't have access to certain x86 opcodes, even though I sure miss the ability to do unpacked decimal arithmetic.

    I hope you don't take this the wrong way -- I encourage your efforts to build the perfect RRM (Record / Relational Mapping) system for your needs, because someone else undoubtably has the same needs and -- assuming your solution works well -- hopefully they will benefit from your contribution.

    At the same time, I hope you will take a moment to consider that other solutions, such as JDO and Hibernate, are also solving real world problems, and solving some of those problems pretty well.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  104. The functionality that you provide is a direct 1:1 mapping (since you gen'd the "records"), which JDO and Hibernate also support. What you don't provide is any other form of mapping.
    You can write a java class by yourself containing record instances. You can change the generated class after generation and add new properties combining the existing ones. In Butler you can also use virtual columns and tables and record listeners, that will enable more complex "mapping".
    The functionality that you provide is done so by generating the classes. In other words, the developer cannot use their own POJOs
    Do you say that the POJOs are created before the database schema is designed. I think that it is better to design the information (database schema) before you design the logic (classes) that should manipulate it.
    In the end, I'm a little surprised that you don't either implement the standard JDO interfaces or at least admit the similarities in approaches and explain the benefits for certain projects of "doing it your way"
    Some of differences between Butler and JDO are:
    * No need for hand-writing POJOs. Butler generates them.
    * No need for mapping configuration.
    * Type-safe queries.
    * Data-aware GUI components relying on database metadata.

    There are similarities too, specially about relation navigation. Before I started Butler, I really considered JDO. The reason I didn't choose JDO was that I wanted to do something that really saved time for developers. Generation of table classes is a real time-saver. Another reason not to use JDO is the lack of database meta-data. The data-aware GUI components needs meta-data.
    to implement the JDO interfaces, and you don't want all your work to be "wasted"
    I think that the last months has showed that skipping JDO was the right solution. The relational model will exists for many more years, but JDO....
    So if you don't like "transparent persistence",
    When Steve talked about "transparent persistence", I thought I was refering to independence of database paradigm. But if the definition of "transparent" is "seamless", I am a big fan.
    in fact I can see with your Butler project that you automatically lose most of the advanced query power of the various databases, since you've hard-coded the possible query operators, and you don't include a lot of the features that (for example) Oracle supports.
    In Butler you have SQLFilter and SQLQuery for creating where-clauses or entire select statements by using raw SQL. And most important. Because Butler does not try to hide the fact that you are using a SQL database, there is nothing that prevent you from calling JDBC directly. But yes, the Query class in Butler can not do everything, but it helps you a lot with the stuff you do 90% of the time. For the other 10%, use JDBC.

    Fredrik Bertilsson
    http://bulter.sourceforge.net
  105. You can write a java class by yourself containing record instances.

    But why should I have to? This isn't necessary with ORMs like JDO.
    Do you say that the POJOs are created before the database schema is designed. I think that it is better to design the information (database schema) before you design the logic (classes) that should manipulate it.

    Again, JDO allows creating the object model before, after, or in conjunction with the schema. Why not allow users to do what's most appropriate for their application?
    Before I started Butler, I really considered JDO. The reason I didn't choose JDO was that I wanted to do something that really saved time for developers. Generation of table classes is a real time-saver. Another reason not to use JDO is the lack of database meta-data.

    Perhaps you should have investigated JDO more thoroughly. Nothing in JDO says the classes can't be generated by a tool; in fact, I believe all the major relational JDO implementations include a tool for generating POJOs and mappings from an existing database schema. Of course, JDO also allows the user to create the POJOs by hand, or to modify the generated ones.

    Additionally, nothing in JDO prevents you from using database metadata or JDBC access. JDO even standardizes runtime JDBC access.

     
    In Butler you have SQLFilter and SQLQuery for creating where-clauses or entire select statements by using raw SQL. And most important. Because Butler does not try to hide the fact that you are using a SQL database, there is nothing that prevent you from calling JDBC directly.

    JDO allows SQL queries and JDBC access too. I really think you should try browsing the JDO 2 spec and/or examining some of the major relational JDO implementations before you try to compare your project to JDO. Thus far everything you've named -- including your own custom query language -- is either a subset of the JDO spec or can be accomplished in a JDO-compliant product.

    I'm sure Butler is great for your needs. But to echo Cameron, consider that other developers might have needs that go beyond your own.
  106. agnostic == dont know what I am doing[ Go to top ]

    I'm sure Butler is great for your needs. But to echo Cameron, consider that other developers might have needs that go beyond your own.

    Actually, I meant different from his own. I honestly believe that with Butler he is addressing real needs that he is personally acquainted with.

    I really hope my previous post wasn't rude (to Frederik or anyone else) .. I was trying to push the conversation back to specific technical differences in approach and implementation, instead of just saying "use more SQL strings" or "use less SQL strings" ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  107. * No need for hand-writing POJOs. Butler generates them.
    * No need for mapping configuration.
    * Type-safe queries.
    * Data-aware GUI components relying on database metadata.

    I believe you are confusing 'specification' with 'product'. For example, there are many JDO products with tools that generate POJOs from schemas, and (fortunately for me) schemas from POJOs. As for the other points, again these features could well be provided by JDO products (I use one that does all the mapping configuration for me)...it is perfectly possible for a JDO-compatible product to parse externally stored JDO queries and validate them against classes and/or schemas, perhaps as an ant task that could be done at run time.

    In order to compare like-with-like, you can't compare with 'JDO', you will need to compare with specific JDO products - OpenAccess, LiDO, Kodo, JPOX etc.
    The relational model will exists for many more years, but JDO....

    JDO isn't going to go away. Whatever happens with JSR 220, the JDO 1.0.1 specification remains. The situation may develop so that companies produce products which continue to implement JDO 1.0.1, and include extensions. These extensions may be proprietary or they may be to a common standard, but there will be persistence products that implement JDO out there for a long time to come. There has been a lot of investment in JDO, and a large developer community using it. Even if JDO becomes 'legacy', the volume of use will mean it will have to be supported for some time.
  108. agnostic == dont know what I am doing[ Go to top ]

    perhaps as an ant task that could be done at run time.

    Of course, I meant 'compile time'!
  109. agnostic == dont know what I am doing[ Go to top ]

    Well said Cameron!
  110. JDO queries *are* objects.

    Yes, the query is an object (interface), but the filter is just a string.

    There's no way to win this argument. You want people to build ASTs (a tree of objects that represent a query) while poor Juozas is bashing anyone who suggests to use anything for programming except for hard-coded SQL strings. Some people say "what's wrong with SQL?" while others are saying "I can't believe you put something into a String!" Stop and listen to yourselves!

    Look, you're each speaking from your own experience, and from your own expertise. Why not sit back and consider -- even if just for a minute -- that the other point of view could have some merit.

    Now Frederik, we know where you stand. You have a megabyte of uncommented code on sourceforge that you forced me to read to understand where you were coming from, since I couldn't glean your actual approach from your derogatory comments here. I don't know your motivations (technical, business, personal) but I'm pretty sure you wrote what you wrote because it helped to solve problems that you had encountered in your own work. So at least your code tells us what your applications need to operate.

    Juozas has already told us his point of view: Whatever alien life form wrote those RDBMS systems, we should never veer from their suggestions because they're super geniuses and they can prove everything with calculus and SQL strings. In other words, Juozas works on applications that map directly and exceedingly well to the RDBMS systems that he is using. That could be because the databases are static, or the development teams are small, or the database schemas are incredibly small, or because he gets to define the schemas himself. Whatever the reason, he won't tell us, because he hasn't realized yet that the problems he solves are not identical to the problems that other people have to solve, so he assumes that everyone else is trying to solve the same class of problems that he is.

    Steve was the only one kind enough to admit to his environment and particular challenges. He said that he uses RDBMS, and also that he's so unfortunate as to be forced to use non-RDBMS for data stores, including flat files. Not only that, he works on projects that have more than one developer (a major reason to consider an ORM, from my own experience, for the same reasons that large projects have DBAs and other forms of specialization).

    The "one size fits all" approach is dangerous. If the JDO proponents tried to claim that JDO were the best solution for everything, they'd be loony. However, the same is true for the "just use SQL" loonies, and the "my framework is the best way for everything" loonies.

    JDO and Hibernate have proved themselves where it matters -- in the field. They're not the only approach, and for some projects, any form of ORM is overkill. If so, then there's always JDBC or (in the middle) frameworks like iBatis: http://www.ibatis.com/

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  111. agnostic == dont know what I am doing[ Go to top ]

    Steve was the only one kind enough to admit to his environment and particular challenges. He said that he uses RDBMS, and also that he's so unfortunate as to be forced to use non-RDBMS for data stores, including flat files.

    Not unfortunate, as I love challenges....
    for some projects, any form of ORM is overkill.

    I have a lot of respect for your views, but may I politely question this? I have found that ORM can be used very lightly, imposing little overhead. Using it can involve just a few calls - it is a real code size saver, which is of benefit in all situations. I would, from personal experience, put things the other way around - for some projects, any form of SQL is overkill. I accept that sometimes, for performance tuning or practical purposes, use of SQL statements or stored procedures is useful (and this is why a good knowledge of SQL is important for Java developers), but these are the exception.

    [I have heard the same argument used regarding OOP - 'for some projects, OOP is overkill', but with Java we use OOP at all scales of coding - we can't avoid it.]

    I am one of those (often unpopular) people who believe that no application should be considered small, as I frequently deal with applications that were not designed for scalability or portability, and where just a bit of thought and effort could have allowed them to scale up. I believe ORM helps with this. I guess that helps explain my bias!

    However, I agree this argument can't be won.

    Just my thoughts....
  112. I have found that ORM can be used very lightly, imposing little overhead. Using it can involve just a few calls - it is a real code size saver, which is of benefit in all situations.
    Agree. Tools like Hibernate is a code-saver. They address an important problem: JDBC and SQL is too wordy. For simple and frequent tasks like finding by primary key, relation navigation, inserting and updating, using JDBC is code bloat. I can't understand why Sun doesn't make a object model on top of JDBC.

    The best thing with ORM is the "R". It must be a relational database. The problem with JDO is that it does not include the "R".

    Fredrik Bertilsson
    http://butler.sourceforge.net
  113. The best thing with ORM is the "R". It must be a relational database. The problem with JDO is that it does not include the "R".Fredrik Bertilssonhttp://butler.sourceforge.net

    One of the intended features of JDO 2.0 was to standardise the Object-Relational Mapping aspects of JDO.

    Just because JDO can be used for MORE than relational, does NOT mean that it does not include relational capabilities.

    look at my post
    http://www.theserverside.com/news/thread.tss?thread_id=31279#153841

    You will see a real-life example of why I believe the versatility of JDO is useful.
  114. Just because JDO can be used for MORE than relational, does NOT mean that it does not include relational capabilities.
    Problem is very simple, I am not going to port any application to object store or to use flat files if I need RDBMS features. I see no problems to call some evil stored prcedure if I need to. I will better tune my application for single RDBMS implemntation and I will tune it again if I will need to in the furute. If I need to port application then probably it means somebody made a wrong decision in the past. I do not use bad products, why do I need to port something ?
  115. agnostic == dont know what I am doing[ Go to top ]

    Problem is very simple, I am not going to port any application to object store or to use flat files if I need RDBMS features.
    And you shouldn't. But what if a good OO db becomes available? Or you app changes and you realize a different "datastore" meets your needs better? Techinically and/or business wise.
     I see no problems to call some evil stored prcedure if I need to.
    Can be done with O/RM products.
    I will better tune my application for single RDBMS implemntation and I will tune it again if I will need to in the furute.
    Can be done with O/RM products and usually applied "globally". From what I have seen, any db specific tuning needed is usually done within the RDMBS and doesn't have anything to do SQL.
    If I need to port application then probably it means somebody made a wrong decision in the past.
    True. With an O/RM there is no porting. Unless one used something like "evil stored procs" :)
    I do not use bad products, why do I need to port something ?
    Because products change. Some get better, some worse. Some vendors merge or disappear. Vendor support gets better or worse. Product prices increase and decrease. And so on. Of course, you are right. If you need to port because of these issues - someone made a BAD decision.
  116. agnostic == dont know what I am doing[ Go to top ]

    I know nothing about future, but SQL works and it works good for me and I do not think SQL conflicts with ORM, it was good before ORM and will be good after ORM.
    I know how ORM is usefull, but I need SQL too. It is very hard to buy compromise with object databses.
    Is it possible to find something less portable than object database ? Do they have programming language neutral standards to integrate applications ? I think I do not need to care about object queries, if I do not care about object databses.
    BTW I see no future for object databases if popular OODBMS vendor more cares about relational databases too.
    http://www.versant.com/resources/documentation/voajdocs/database_specific_information.html
  117. I know nothing about future, but SQL works and it works good for me and I do not think SQL conflicts with ORM, it was good before ORM and will be good after ORM

    Sorry, but if you know nothing about the future, how do you know that SQL will be good after ORM? You are contradicting yourself.
  118. If I need to port application then probably it means somebody made a wrong decision in the past. I do not use bad products, why do I need to port something ?

    Because you can't see the future. Today's right decision is tomorrow's wrong decision. [One of my (large) list of current projects is porting a substantial legacy database - which used a proprietary non-standard version of SQL - into something modern. The use of that database was the right decision (not mine) at the time - it was a good product, fast and reliable. Then the company that made it went broke.]

    Suppose there was some new database technology. Let's call it Relational++, using SQL++. Your approach means you can't use these new features, you are trapped into the pure relational (and SQL) approach.

    With JDOQL you simply express what you want to retrieve. It is up to the JDO product vendor to provide an optimised method of retrieving that data. The JDO vendor almost certainly understands more about how the storage mechanism works than I do - they have spent time researching the hypothetical SQL++, while I have been busy coding.

    The real benefit is that I don't have to touch my old JDO code - I simply plug in this vendor's new driver for SQL++ and my old code makes use of this new technology.
  119. The real benefit is that I don't have to touch my old JDO code - I simply plug in this vendor's new driver for SQL++ and my old code makes use of this new technology.
    So it means JDO implementation needs this new super technology to sell me new version. If new features are "transparent" for me, then probably I can live without them too.
  120. The real benefit is that I don't have to touch my old JDO code - I simply plug in this vendor's new driver for SQL++ and my old code makes use of this new technology.
    So it means JDO implementation needs this new super technology to sell me new version. If new features are "transparent" for me, then probably I can live without them too.

    Let's take an analogy with Java. There is increasing use of 64-bit processors. They provide higher performance. The use of this performance is 'transparent' (using the term in the way you have) if you use Java - you don't need to put any effort into using it - you allow the Java VM producer to do all the work to support the new technology.

    Would you say that because 64-bit features are 'transparent', that you can live without them? Are you only interested in new technologies that you have to actually make an effort to support?

    Why should the ability of JDO to give you access to future technologies with no effort on your part be a problem?
  121. With JDOQL you simply express what you want to retrieve.
    You could say the same thing about SQL. "It simple express what you want to retrieve". If it is possible to have a JDO interface to the next generation of databases, it would also be possible to have a SQL driver.

    Do you really think that a programming-specific query language can replace a neutral query language? If the world needs a new query language, wouldn't it be better to create one that can be used from all programming languages.

    Fredrik Bertilsson
    http://butler.sourceforge.net
  122. Do you really think that a programming-specific query language can replace a neutral query language? If the world needs a new query language, wouldn't it be better to create one that can be used from all programming languages.Fredrik Bertilssonhttp://butler.sourceforge.net

    Yes, it would - I agree with you - I think this is an excellent idea. If such a language existed, it could be used as the basis for all querying, both in and out of ORMs. But, I really can't see this happening.

    An equivalent would be if all processor designers came up with a single machine code that that could be used on all hardware. In that case, we would not need VMs. Our binary code could run everywhere. Unfortunately, we need VMs, which do a superb job, translating our java byte code to very high-performance machine code for the specific processor we deploy on, making best use of all the features of that individual processor, not some subset, which would be the case for compiled code.

    In the same way, our ORM technologies do a good job, translating our portable query languages into high-performance SQL for the specific database we are using, making best use of all the features of that particular database, not some subset, which would be the case if we used portable SQL.
  123. agnostic == dont know what I am doing[ Go to top ]

    I have a lot of respect for your views, but may I politely question this? I have found that ORM can be used very lightly, imposing little overhead. ... I would, from personal experience, put things the other way around - for some projects, any form of SQL is overkill.

    I agree Steve. I think, though, that Cameron was leaving some room for error. I am sure sometime, somewhere that it would be the case. The only case I have come across is something quick-and-dirty that I know I will through away. Other than that ... .
  124. agnostic == dont know what I am doing[ Go to top ]

    I have a lot of respect for your views, but may I politely question this? I have found that ORM can be used very lightly, imposing little overhead. ... I would, from personal experience, put things the other way around - for some projects, any form of SQL is overkill.

    I agree Steve. I think, though, that Cameron was leaving some room for error. I am sure sometime, somewhere that it would be the case. The only case I have come across is something quick-and-dirty that I know I will through away. Other than that ... .

    Actually, there are a lot of "dynamic" uses that straight SQL (with its "by name" or "by index" support with rich meta data) is optimal for. Anything that looks like reporting, or run-time designable selection (horizontal or vertical) is much better served by a loosely coupled API, as provided directly by JDBC.

    And to be honest, I like the general approach with Butler's "records" for that type of functionality, because it exposes the core data as both specific accessors / mutators (with the gen'd class example) and as positional (position within a row). So for building a reporting tool, you could use something like Butler, and either drop the code gen aspect, or pass your objects to the reporting engine, but the reporting part would only use the "generic get/set by index" interfaces of the objects.

    There are many, many different kinds of applications. I am a believer in ORM because I've seen it work. However, I don't assume that it's the best fit for every application.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  125. agnostic == dont know what I am doing[ Go to top ]

    Actually, there are a lot of "dynamic" uses that straight SQL...

    If there were such a thing as 'straight SQL', I would agree with you. I guess I am just putting forward the views of a developer with decades of experience of dealing with code that has become unsupportable because it is tied in to a specific technology or vendor that is no longer supported. When someone suggests coding SQL, I get a bad feeling that they are storing up trouble. I have plenty of examples of so-called 'straight SQL' that has ended up stored in floppy discs, gathering dust on a shelf because there is no application that supports it.
    I am a believer in ORM because I've seen it work. However, I don't assume that it's the best fit for every application.

    Because of my long and bitter experience of past failed projects (not all mine!) I always advise that developers use technologies that provide portablility and vendor independence. In the long term, its not always the best fit that matters.
  126. Juozas has already told us his point of view: Whatever alien life form wrote those RDBMS systems, we should never veer from their suggestions because they're super geniuses and they can prove everything with calculus and SQL strings. In other words, Juozas works on applications that map directly and exceedingly well to the RDBMS systems that he is using. That could be because the databases are static, or the development teams are small, or the database schemas are incredibly small, or because he gets to define the schemas himself. Whatever the reason, he won't tell us, because he hasn't realized yet that the problems he solves are not identical to the problems that other people have to solve, so he assumes that everyone else is trying to solve the same class of problems that he is.

    Believe it or not, but we use JDO in our company.
  127. Look, you're each speaking from your own experience, and from your own expertise. Why not sit back and consider -- even if just for a minute -- that the other point of view could have some merit.

    I don't know what you want me to do. I am trying to debate the problem that many developers tries to hide the fact that they are using relational databases. Maybe you should sit back and consider why the java community have come into this misarable situation regarding database framworks. First the failure of EJB and now the failure of JDO. The natural solution would have been to extend JDBC with classes such as Table, ForeignKey, Query and Record.
    So at least your code tells us what your applications need to operate.
    I am not sure I understand you questing. Anyway, Butler needs a JDBC-driver that supports ANSI SQL. That's all.
    If so, then there's always JDBC or (in the middle) frameworks like iBatis.
    Butler is also a framwork in the middle. It is an object model on top of JDBC.

    Fredrik Bertilsson
    http://butler.sourceforge.net
  128. Using a O/R mapper is more productively than using JDBC in most cases. But I think that complex O/R mapping (other than 1:1 between table and class) disables you to use some of the features in a relational database and it forces the programmer to do unnecessary mapping configuration.
    Complex mapping does not exist if DB shema is correct. There are a few rules to transform valid conceptual model to implementation . All good ER modeling tools do it automaticaly. But valid implementation model is a valid conceptual model too and there is nothing wrong to use this model in application without any transformation, it is designed for implementation/application by definition. I think the most pragmatic way is to generate this stuff, it is not important how generated is implemented, it can use O/R,JDO,EJB or JDBC. It is a garbage anyway.
  129. I don't get what you are saying here...how is putting the data into a class 'better' than a resultset?
    String x = myObj.getMyField(); or
    String x = rs.getString("MyField");
    What's the difference?
    </blockqoute>
    Software quality and development time. In the first solution, you can use code-completion in your IDE and if you type the wrong field name, you will have a compilation error instead of runtime error.
    At least with ResultSet I can easily query the metadata, with an object you have to resort to some ugly reflection hack.
    If you would have Record objects, you could have a getTable()-method to get access to meta-data.
    A class for each table huh? Code bloat.
    Not if the classes is generated from the database schema.

    <blockqoute>
    These mapping files are the mother of all evil and just another thing to get throughly screwed up.
    Agree. Mapping files is unnecessary in most cases. Mostly the only resonable mapping is one-to-one between table and class. Only the exception from this rule should using hand-coded mapping.

    Fredrik Bertilsson
    http://butler.sourceforge.net
  130. time is now[ Go to top ]

    JDO experts have been participating in JSR-220 since end of Septemeber and their efforts and participation have greatly enhanced the current JSR-220 spec draft. Let's continue to deepen this collaboration so the finalization of JSR-220 can be hastened and the Java community can get what they've been asking for: A unified persistence specification that covers both J2SE and J2EE. Bill
    You're right to say the time is now. The time is now to give current JDO users a meaningful enhancement to the framework. The time is now to deliver a version of JDO that removes some of the barriers to adoption from 1.0. The time is now to begin moving JDO toward unified Java persistence, but JDO 2.0 has NEVER been dependent on JSR-220, and it shouldn't be now. Let them release a solid maintenance version consistent with the ideas you're working on in the unified persistence spec, and finish the unification later.
  131. time is now[ Go to top ]

    Releasing JDO 2.0 now would otherwise be benefitial to future acceptance of EJB3, since projects would consider going POJO now instead of waiting for EJB3, paving the road to EJB3 migration in the future. Let EJB3 take JDO 2.0 as a reference, and when done, the migration path will be clear and simple.

    Regards,
    Henrique Steckelberg
  132. time is now[ Go to top ]

    JDO experts have been participating in JSR-220 since end of Septemeber and their efforts and participation have greatly enhanced the current JSR-220 spec draft. Let's continue to deepen this collaboration so the finalization of JSR-220 can be hastened and the Java community can get what they've been asking for: A unified persistence specification that covers both J2SE and J2EE. Bill
    You're right to say the time is now. The time is now to give current JDO users a meaningful enhancement to the framework. The time is now to deliver a version of JDO that removes some of the barriers to adoption from 1.0. The time is now to begin moving JDO toward unified Java persistence, but JDO 2.0 has NEVER been dependent on JSR-220, and it shouldn't be now. Let them release a solid maintenance version consistent with the ideas you're working on in the unified persistence spec, and finish the unification later.

    Well said. I wonder how relevant this vote is anyway? Most of the Vendors have already moved ahead and implemented features from the draft proposal.
  133. The vote is very relevant[ Go to top ]

    Steve asks:
    I wonder how relevant this vote is anyway?

    This vote and the next 4 weeks are absolutely critical. Under JCP rules (sorry to be a bore!) the JSR-243 Expert Group has exactly 4 weeks within which to deliver a revised Public Draft Specification which meets the concerns raised by the JCP Executive Committee members. Failure to do so will result in the JSR being closed. This would remove from us the JCP mandate for our work.

    Kind regards, Robin.
  134. The route forward[ Go to top ]

    Hello Everyone

    JDO 2.0 is a fully backward-compatible enhancement of JDO 1.0.1 which addresses the requirements of the JDO community. 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. These are inline with the original specification request under which our JCP mandate was granted.

    It is not yet clear whether we must actually change the specification in material ways (I suspct this is indeed the case) or whether the EC can be won over by clarifications regarding the positioning of JDO and the efforts which are underway to have migration paths to EJB 2.0 Persistence defined.

    It is expected that the JSR-220 group will deliver a second Early Draft spec before proceeding to their own Public Draft and ballot. Since we have just 4 weeks and the second JSR-220 Early Draft spec is not yet available I am slightly unsure of the JCP Executive's intentions in this regard. However, liaison with each of the Executive members is underway to establish the appropriate route forward.

    Kind regards, Robin.
  135. The vote is very relevant[ Go to top ]

    Failure to do so will result in the JSR being closed. This would remove from us the JCP mandate for our work.Kind regards, Robin.

    Well, considering this rejection and the nature of some of the objections to the draft, would this be disastrous? Perhaps it would stimulate JDO vendors to move together to form a persistence standard outside of the JCP where the efforts to progress JDO are not being held back. There are many Java 'standards' (Eclipse plug-ins for example) that are widely implemented and have nothing to do with the JCP. I used to consider the JCP to be of benefit to the developer community, but this depressing state of affairs with JDO 2.0 seems to be driven by the commercial interests of vendors, not the requirements of developers.
  136. +1[ Go to top ]

    Agreed. Probably another 1.5 years will be enough ROI on the EJB2x products for them to make a switch.

    Who determines that the vendors and not users are in the JCP Expert Groups anyhow? That seems to be the big problem - solutions driven by suppliers and not consumers. You don't have to be a business student to see this is a recipe for disaster.

    Let Apache take JDO and be done with it.
  137. It's the EC, not the EG...[ Go to top ]

    Just for the record:

    The SE/EE Executive Committee cast the ballot, not the Expert Group.

    Expert Committee members are elected by the members of the Java Community Process. For individuals, JCP membership is free. Become a member, vote in elections, participate in expert groups.

    Expert group members are nominated by JCP members, too.
  138. Just for the record:The SE/EE Executive Committee cast the ballot, not the Expert Group.Expert Committee members are elected by the members of the Java Community Process. For individuals, JCP membership is free. Become a member, vote in elections, participate in expert groups. Expert group members are nominated by JCP members, too.

    Super example of the effects of a representative democracy. Seems like those vendors with interests to protect can find the way to load the JCP with members to vote them intothe executive committees and in the end the little guy gets screwed.

    I'll save this thread and look back in 10 years and see how the markets deal with this issue.
  139. Democracy[ Go to top ]

    I'm afraid I disagree. Given the fact that JCP membership is free of charge for individuals, I find it hard to understand that there so few individuals have in fact joined the JCP. Voicing opinions and expressing dissatisfaction on TSS is not the only thing individuals can do to influence processes in the Java community--don't blame the vendors if the individuals don't make use of the opportunities they have.

    (I'm not associated with any vendor; as a JDO user and an individual member of the JSR-243 EG I'm certainly not happy about the outcome of the ballot.)
  140. Democracy[ Go to top ]

    Hi Oliver,

         I agree completely with your statement about individuals. I am also an individual member of the JCP and although not involved with this JSR hope to encourage individual participation. Vendors provide great depth and expertise to JSRs but individuals can provide objectivity and can offer support for the position of the end user. Hopefully we will get more individuals participating in many JSRs in the future.

    Thanks,
    John Harby
  141. +1[ Go to top ]

    .Let Apache take JDO and be done with it.

    What an excellent suggestion! I suspect that a 'Jakarta JDO' (or whatever it might end up being called) would have far more influence and use in the Java developer community than a specification which has been constrained to appease EJB vendor concerns.
  142. The vote is very relevant[ Go to top ]

    Hi Steve

    Let's not strategise about JDO outside the JCP. Java's strength is the Java Community Process. This process has allowed individuals such as me and corporate members to participate side-by-side in the evolution of technology. Within each Expert Group (JSR) the votes of individual and vendor members are (at the discretion of the spec lead) counted equal. Final decisions (regarding the approval for JSRs to commence, authorizing the delivery of an RI & TCK based upon a public draft spec, and final adoption of a standard, are taken by the Executive Committee. The seats on this committee are occupied by individuals and vendors elected, for a designated term, by the whole JCP membership. Only Sun has a permanent seat.

    I believe these principles and processes are good. If you disagree with the direction the JCP Executive is taking you should become a member of the JCP (individual membership is free!) and use your voting rights to influence the structures over time. But, unless it can be shown that the Java Community Process is no-longer serving the best interests of the Java Community, it would be wrong to make plans t undermine it's standing and authority.

    Naturally, expressions of support from the Community (that's everyone who reads this) for JSR-243 certainly will not hurt.

    Kind regards, Robin.
  143. The vote is very relevant[ Go to top ]

    Hi SteveLet's not strategise about JDO outside the JCP. Java's strength is the Java Community Process. This process has allowed individuals such as me and corporate members to participate side-by-side in the evolution of technology. Within each Expert Group (JSR) the votes of individual and vendor members are (at the discretion of the spec lead) counted equal. Final decisions (regarding the approval for JSRs to commence, authorizing the delivery of an RI &amp; TCK based upon a public draft spec, and final adoption of a standard, are taken by the Executive Committee. The seats on this committee are occupied by individuals and vendors elected, for a designated term, by the whole JCP membership. Only Sun has a permanent seat.I believe these principles and processes are good. If you disagree with the direction the JCP Executive is taking you should become a member of the JCP (individual membership is free!) and use your voting rights to influence the structures over time. But, unless it can be shown that the Java Community Process is no-longer serving the best interests of the Java Community, it would be wrong to make plans t undermine it's standing and authority.Naturally, expressions of support from the Community (that's everyone who reads this) for JSR-243 certainly will not hurt.Kind regards, Robin.

    Hi Robin,

    You make good points, and perhaps I was too harsh about the JCP as a whole, as it has, in general, worked very well over the years. However, there does seem to be a particular issue with this JSR, and your timetable for events suggests that there could be problems in addressing these issues in time to keep JDO on track within the JCP. My impression is that JDO has always been controversial and there have always been vested interests that, for understandable commercial reasons, would rather JDO did not succeed. No matter how excellent the JCP has been in other respects, it is surely a failing of the process if this JSR is closed leaving the impression (even if it is false) that these vested interests have used the JCP for this purpose. Such an impression (which I believe would be widely held) devalues the entire JCP.

    My concern as a developer is that there should be a high-quality full-featured multi-vendor standard for POJO. The vote on the draft, and the comments accompanying it, lead me to doubt that the JCP in this instance may not be capable of delivering this.
  144. The vote is very relevant[ Go to top ]

    Hi Steve
    My impression is that JDO has always been controversial and there have always been vested interests that, for understandable commercial reasons, would rather JDO did not succeed.

    Agreed, but I think we're talking "historically" here. The position in which JDO finds itself today (with 10 votes against) cannot be explained in terms of vested interests alone. The confusion arising from the espoused alignment of JDO and EJB Persistence is genuine and worthy of clarification, although excacly what is required on JSR-243's part is not yet clear.

    Thanks for your comments - good calibre debate.
  145. The vote is very relevant[ Go to top ]

    HThe confusion arising from the espoused alignment of JDO and EJB Persistence is genuine and worthy of clarification,

    What concerns me is that this confusion has been obvious for a long time; since shortly after the announcement of the new POJO specification. The initial enthusiasm for the announcements (I heard reports from Java One) was soon tempered by a lack of clarity about the intentions regardihg JDO. It seems rather late in the day to try to address this matter now, which is why I have been pondering how JDO (or a successor) is likely to evolve outside the JCP.
     
    although excacly what is required on JSR-243's part is not yet clear.

    If Sun were to fulfill their promise, as stated in their 'Letter to the Java Technology Community' to 'bridge the communities' (EJB and JDO), it would be reasonable to expect some work from JSR-220 to assist with the situation. A bridge has two ends!
    Thanks for your comments - good calibre debate.

    Thank you. I am only trying to put forward the opinions of a typical,(albeit distinctly confused in this matter) developer.
  146. The vote is very relevant[ Go to top ]

    What concerns me is that this confusion has been obvious for a long time; since shortly after the announcement of the new POJO specification.

    It seems that I and my fellow JDO Expert Group members must pay the price for this "confusion", but I do not believe it was us that created it. Anyway, that's water under the bridge, and now I only have 3 weeks and 6 days left....
  147. The vote is very relevant[ Go to top ]

    What concerns me is that this confusion has been obvious for a long time; since shortly after the announcement of the new POJO specification.
    It seems that I and my fellow JDO Expert Group members must pay the price for this "confusion", but I do not believe it was us that created it. Anyway, that's water under the bridge, and now I only have 3 weeks and 6 days left....

    If one makes a distinction between members of the expert group and the companies who those members belong to, then I am prepared to agree that the members themselves did not create the confusion!

    Anyway, good luck. Although I have confidence that the work done towards making JDO a standard will survive no matter what happens, I would personally rather it was a JCP standard.
  148. I already suggested in the past that the JCP wasn't the right place for JDO and that continuing it outside of it would mabye the best thing. See http://www.theserverside.com/discussions/thread.tss?thread_id=30686

    So I'm not one bit surprised that JDO2.0 got 'the boot'. I think this shows that JDO doesn't really have a future...

    Oh well, I'll just use Hibernate. **** EJB3.0, Spring rules!
  149. Is it time for action???[ Go to top ]

    Hi,

    It is amazing how politics can stop something that looks like such a big step forward.

    Why should we wait one more year for a "sub-set" of JDO 2.0?

    Is there a way to put presure on the vendors for show them that sometimes they should look a bit further than their own agenda?

    I am really indignant about that, it is the 2nd time!!!

    Best regards,
    Cheers,
     JD
  150. 1.If JDO will be dropped what can be used as standard for developing standalone DB-aware applications (which couldn't use middleware app server). As I know EJB3 can be used outside the container only for testing purposes. I'm correct?

    2.And due to the version attribute is required to be present in the database for EJB3 we can't use our legacy DB structure which doesn't contain this version attributes.
  151. 1.If JDO will be dropped what can be used as standard for developing standalone DB-aware applications (which couldn't use middleware app server). As I know EJB3 can be used outside the container only for testing purposes. I'm correct?2.And due to the version attribute is required to be present in the database for EJB3 we can't use our legacy DB structure which doesn't contain this version attributes.

    Sorry, Alexander, but wrong on both counts. The new EJB3 POJO persistence is usable independently outside the container. And you can map to a legacy schema no problem.
  152. 1.If JDO will be dropped what can be used as standard for developing standalone DB-aware applications (which couldn't use middleware app server). As I know EJB3 can be used outside the container only for testing purposes. I'm correct?2.And due to the version attribute is required to be present in the database for EJB3 we can't use our legacy DB structure which doesn't contain this version attributes.
    Sorry, Alexander, but wrong on both counts. The new EJB3 POJO persistence is usable independently outside the container. And you can map to a legacy schema no problem.

    I second Scott on both of these counts.
  153. Thank for all who answer me.
    But I confused: if EJB3 can do same as JDO why there is so many objections about merging this two technologies?

    Why JDO vendors can't simply move to the EJB3 API?

    As I understand main goal of EJB 3.0 (JSR-220) is to make one persistent standard for Java getting the best from JDO and EJB worlds?

    Or that people who write this often mentioned letter (http://java.sun.com/j2ee/letter/persistence.html) means that Java community should choose one standard among EJB and JDO. And do this choose by himself(and with some rich folks) choosing EJB and simply ignoring all JDO users?
  154. Thank for all who answer me.But I confused: if EJB3 can do same as JDO why there is so many objections about merging this two technologies?Why JDO vendors can't simply move to the EJB3 API?

    1.- Because the new EJB3 API is at least on year away

    2.- It should be the way arroung, EJB3 persistence API will be a "new product", JDO is a very mature one.
  155. But I confused: if EJB3 can do same as JDO
     why there is so many objections about merging this two technologies? Why JDO vendors can't simply move to the EJB3 API?

    One word: Users. JDO actually has people using it, and they'd like their code to work without rewriting it when JDO2 comes out.

    The reason that they call it JDO2 is because there already is a standard called JDO1 (and also JDO1.0.1).

    Suggesting that they just switch over to the EJB API is about as realistic as suggesting that anyone using the JDBC API should just change all their code to use the EJB API. And before you suggest that it's a ludicrous example since the server implementations of EJB are built on top of JDBC, remember that several server implementations of EJB are built on top of JDO.

    Not counting the Oracle and JBoss votes (which won't change even if JDO cures cancer), the problem with the JDO2 JSR is that several of the EC members that voted "no" want to make absolutely sure that JDO2 isn't going to conflict with the EJB3 API, particularly with regards to persistence. It's quite likely that those concerns will be addressed over the next several weeks.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  156. It's called "don't screw the user"[ Go to top ]

    the problem with the JDO2 JSR is that several of the EC members that voted "no" want to make absolutely sure that JDO2 isn't going to conflict with the EJB3 API, particularly with regards to persistence.

    I wonder why it is this way round? As JDO is an existing mature API, and Sun has stated the intention of 'bridging the [JDO & EJB] communities', perhaps the question should be asked as to why the EC members aren't working to make sure that the EJB3 POJO API isn't going to conflict with JDO 2.
  157. 1.If JDO will be dropped what can be used as standard for developing standalone DB-aware applications (which couldn't use middleware app server). As I know EJB3 can be used outside the container only for testing purposes. I'm correct? .

    Yes. The intent of JSR 220 persistence is to define the persistence model for both J2EE and J2SE as Bill Burke indicated in an earlier posting
    2.And due to the version attribute is required to be present in the database for EJB3 we can't use our legacy DB structure which doesn't contain this version attributes.
    Yes, you should be able to do this. Version attribute is required only when you optimistic locking. AFAIK this is required by most O-R frameworks available in the market

    regards
    Debu
  158. 1.If JDO will be dropped what can be used as standard for developing standalone DB-aware applications (which couldn't use middleware app server).

    I don't see JDO being dropped in the near future, as there are many commercial and open-source vendors providing it and tens of thousands of developers already using it. Implementations which contain major features of JDO 2.0 are already available now. There is nothing to stop these vendors working together to provide a standard API based on JDO 2.0 (perhaps with a new name?) independently of the JCP, if progress towards JDO 2.0 is going to be stifled like this.
  159. I guess one thing we can do is send an email to the expert group members that voted against JDO 2, and let them know that we want to see JDO 2.0 passed, and that we the customers should be the ones to decide whether we want to use JDO or not.

    The list of expert group members that voted against JSR 243 (or abstained) are:

    BEA Systems - Ed Cobb - ed dot cobb at bea dot com
    Fujitsu Limited - Masahiko Narita - masahiko dot narita at jp dot fujitsu dot com
    Google - Josh Bloch - jjb at google dot com
    Hewlett-Packard - Scott Jameson - scott dot jameson at hp dot com
    IBM - Mark Thomas - mthomas at uk dot ibm dot com
    IONA Technologies - Becky Bergersen - rebecca dot bergersen at iona dot com
    Intel - Wayne Carr - wayne dot carr at intel dot com
    JBoss - Sacha Labourey - sacha dot labourey at jboss dot com
    Nortel Networks - Bill Bourne - billb at nortelnetworks dot com
    Oracle - Don Deutsch - donald dot deutsch at oracle dot com
    SAP - Michael Bechauf - michael dot bechauf at sap dot com

    I for one will be sending these people an email to let them know that I want to see JDO 2.0 passed by the JCP,

    Dave.
  160. Need we really care? It is clear what kind of openness the JCP offer for us, so please instead of wasting time, better I inveite people to join the Apache JDO effort. We don't need an JCP approval after all. See some other projects as Ant that even today are not under the JCP umbrella and are de-facto standards.
  161. JDO 2.0 Public Review Ballot[ Go to top ]

    Anyone who complains about the vote should have joined the JCP and used their vote to prevent some obvious twats from making the EC.

    Rock the vote. I'm definitely voting for Hani next time. ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  162. Hani...[ Go to top ]

    I voted for him this time!
  163. JDO 2.0 Public Review Ballot[ Go to top ]

    Anyone who complains about the vote should have joined the JCP and used their vote to prevent some obvious twats from making the EC

    As someone who tries to be diplomatic whenever possible, I would not have put it quite so .... wonderfully bluntly :)

    Anyway, I don't agree. Sun is a commercial company. It's up to Sun to do their best for their customers. In the case of Java JSRs, their main customers are the developer community. If Sun produce an inadequate specification or product, it is not the customer's fault! The JCP was set up by Sun, and they are responsible for the way it works. They could have introduced rules to prevent undue vendor influence or potential conflicts of interest.

    If Java was a totally open source community project produced and maintained by unpaid volunteers, then I would feel more of an obligation to spend time potentially helping with the development and direction of the project. Until that unlikely situation, surely it's up to Sun to actively contact and question developers about what they want and need, and not to sit back and wait for developers to join a process (the JCP) that many of heard of but few understand. I have been using JDO for over a year (since I first downloaded the RI), but there has been no effort from Sun to let me know about the relevant JSRs and who was involved, and what might result, or why I should join the JCP.
  164. JDO 2.0 Public Review Ballot[ Go to top ]

    Good Point. Hani it is next time! :-)
  165. Sadly, another year to wait...[ Go to top ]

    It's the user that is most impacted. Quite a lot of
    users have been waiting for a
    currently-market-available light-weight persistence
    API all along, and JDO2.0 gives the power.

    While, as a user, I have to admit that JDO2.0 adds
    many functions and makes it like a replacement of EJB,
    and this does bring much confusion.

    I believe that after aligning with JSR220, JDO vendors
    could easily implement the new persistence API with
    their already mature kernels. And users could only
    wait for probably another year for EJB3 to power up
    their existing JDO applications...
  166. sabotaging JDO's market momentum[ Go to top ]

    The absence of technical objections to JDO 2.0 and the recurring theme of confusion with JSR 220 persistence indicates that the purpose of the votes against JDO 2.0 are to prevent JDO 2.0 implementations (which many JDO vendors are already making preview releases available) from gaining market momentum before JSR 220 persistence implementations appear for the first time.

    Their fear is not "market confusion". It is market certainty that proven JDO 2.0 implementations will reach the market and achieve broad success (market share) long before JSR 220 persistence reaches the market, thereby relegating JSR 220 persistence to irrelevance. They know that successful adoption of a technology will make it virtually impossible to displace with an alternative that arrives late, even if it exhibits some modest degree of superiority. The technology with dominant market share will also not remain stagnant, and its vendors would quickly incorporate improvements according to demand.

    There is a large community of developers with both money and expertise to invest in adopting a prolific persistence technology. It is a ubiquitous problem for many applications. There is fear that JDO 2.0 will be adequate to the needs of many, rendering the promise of JSR 220 persistence irrelevant, if JDO 2.0 is widely adopted quickly. The only confusion that would be ensue is the consequent irrelevance of JSR 220 persistence to the market.

    Therefore, I would suggest that if the Java Community Process is acting against the interests of the community that it proports to serve by sabotaging a technology that the community demands, the JDO vendors should release their products according to the latest available draft without the endorsement of the JCP Executive Committee. The market can vote with their hearts, minds, and dollars; the politically motivated votes in favor of JSR 220 persistence would merely become a hollow victory for the opponents of JDO 2.0.
  167. sabotaging JDO's market momentum[ Go to top ]

    I totally agree with Ben. The intent EJB lobby was very clear since JDO was made part of EJB Specs. At that time everyone on expert group including JDO vendors (not that they had much choice in the matter) assured public that JDO will take its rightful place in persistent specs. Well, it does not look this way. I hope reality will prove me wrong - we have been using JDO for 3 years and heavily dependent on it
  168. Can the Apache Software Foundation take the lead and in conjunction with Expert Group members, JDO vendors, and other interested parties complete the development of JDO 2.0 otherside of the JCP environment?

    This would be appreciated by many organisations and individuals, and people who want to use other approaches are free to do so.

    Bruce.
  169. In this post, I will argue that the real reason JDO 2 is being delayed is that several members of the expert group have a vested interest in seeing JDO fail, and that dropping JDO 2 would be a disaster for current JDO users.

      Before we begin, it's important to note that no one voted against this on technical grounds. Essentially, everyone recognizes that this spec is what the customers want. It's backward compatible with JDO 1. Every feature is based on customer feedback. JDO 2 is a good spec.

      Now, let's look at the logic given by the no votes. They claim that advancing JDO will confuse the market by encouraging multiple persistence standards. News flash: we already have multiple persistence standards. This might have been a valid argument against JDO 1, but now that JDO has hit the Java world, holding it back will not make it easier for developers to switch to EJB 3. What it will do is create several problems for JDO users.

      The first problem with nixing this spec is that EJB 3 is much farther away than JDO 2. It's absurd to expect JDO users to sit and wait while EJB 3 is hashed out, when an excellent solution has been presented in JDO 2. Further, stopping JDO 2 will not stop vendors from implementing the spec, it will simply ensure that all the vendors have their own, slightly different mechanisms. Developers need the enhancements in JDO 2 and will tie their code to these vendor-specific solutions, clearly to their detrement. Passing JDO 2 is good for current JDO users. Delaying until EJB 3, even if that spec is eventually completed and satisfactory, hurts JDO users. Then again, most of the no votes have a vested interest in seeing JDO users suffer. What does JBoss gain if JDO 2 is fantastic?

      The second problem with killing this spec is that JDO 2 includes features that aren't included in EJB 3. The proposed fetch group mechanism is one example, and JDO 2's support for non-relational stores is another. Now, maybe Oracle doesn't care about non-relational databases. You can be sure that many JDO users do though. Preventing the advance of JDO 2 leaves them high and dry.

      Finally, it's not clear that the EJB 3 spec is really going to be the best option for current JDO users. There is a tremendous conflict of interest between the various EJB, JDO, and DB vendors involved in this spec. For example, is this team going to incorporate the more flexible JDO 2 object-relational model into EJB 3? Are they going to provide a mechanism for executing JDOQL? Maybe, but until they do, developers may decide they are better off sticking with JDO and not migrating. Should we prevent them from doing so? Hardly.

      If EJB 3 truly lives up to it's stated goal of providing a unified persistence mechanism, the market will recognize this and the need to continue JDO independently will cease. In my own work, I use EJBs for remoteness, security, etc, and JDO for persistence. A unified persistence mechanism would make a lot of things easier for me. I want to see a good, unified spec. Until this happens though, development of JDO should continue. It is idiotic to prevent a much needed JDO spec enhancement when there is nothing comparable currently available. To make this move with the claim that something similar may or may not be available a year later is obviously not in the best interest of developers.

      So why has the spec been shot down? The real answer is that EJB vendors have a vested interest in seeing JDO go away as quickly as possible. If JDO 2 passes and JDO development continues, they will be forced to truly make EJB 3 compatible with JDO. If they don't, JDO users just won't migrate. With JDO 2 dead and JDO users struggling with the problems that spec is intended to address, EJB vendors hope that JDO users will be forced to move to EJB 3, whether there is a comfortable migration path or not, and, more importantly, whether EJB 3 is better than JDO 2 or not. The stated concerns about "confusion" are just the best they could come up with to justify voting the spec down.

      The JDO development community should not stand for this. JDO 2 must be adopted as a persistence specification if we are to have any hope of EJB vendors playing fair in the development of EJB 3. We cannot kill JDO and then write the unified persistence spec. We must continue to develop JDO until a unified spec appears and makes a legitimate case that it is a better alternative.


        Sincerely,
         Eric Lindauer
  170. JCP is Flawed[ Go to top ]

    What I find crappy about the JCP is that the JSR-243 Expert Group contains vendors:

    * DO NOT PROVIDE A JDO IMPLEMENTATION
    * HAVE NEVER PROVIDED A JDO IMPLEMENTATION
    * HAVE NO INTENTION OF EVER PROVIDING A JDO IMPLEMENTATION

    Does that make sense?

    Representative democracy is very easily corruptable, as we see.
  171. JCP is Flawed (not my assertion)[ Go to top ]

    What I find crappy about the JCP is that the JSR-243 Expert Group contains vendors:* DO NOT PROVIDE A JDO IMPLEMENTATION* HAVE NEVER PROVIDED A JDO IMPLEMENTATION* HAVE NO INTENTION OF EVER PROVIDING A JDO IMPLEMENTATIONDoes that make sense?Representative democracy is very easily corruptable, as we see.

    Hi Jon

    Many stakeholders have an interest in a technology. Some of them write the spec, some implement the spec, some user the implementations, some educate the community, some merely observe and occasionally contribute to the debate. All of this makes the debate healthy. This is how it should be.

    There are no JDO expert group members which I believe should not be members. Furthermore, the JSR-243 expert group discussion list is actually subscribed to by many who are not officially Expert Group Members (you have to be a JCP member first) but who have an interest in JDO and its evolution. If some who participate in the discussion have competing products that does not necessarily devalue their participation.

    My only regret about the membership of JSR-243 is that Gavin King (Hibernate) and Mike Keith (Oracle) chose to leave.

    To Mike: belated congratulations on 10 years of TopLink persistence, and apologies for not having said so sooner.

    Kind regards, Robin.
  172. JCP is Flawed (not my assertion)[ Go to top ]

    If some who participate in the discussion have competing products that does not necessarily devalue their participation.

    I believe there is a real problem with the perception of such a situation, whatever the reality. It may well be the case that participants who are members of companies that have competing products are happy to help with the development of a standard API that provides an alternative to their product. But, if this JSR fails, and the votes against seem to be mainly from such participants, and the reasons seem to be political rather than technical, then surely it's going to be inevitable that the motives of these participants are going to be questioned.

    Although I know little about the JCP, I feel there must be a problem with the process if we have ended up in this situation, in which the question of conflict of interest can arise, and so many developers are complaining.
  173. JCP is Flawed (not my assertion)[ Go to top ]

    I think it's wonderful that Robin Roos and all other involved have the energy and will to make JDO 2.0 through the JCP. Kudos for that!

    But, if these 4 weeks will end up in a new No-vote again, I tend to appreciate Steve Zara's view that the real JDO vendors should go for their own "JCP" route, perhaps in cooperation with Apache.

    As a user of JDO, I am sinecerely dissapointed by the J2EE vendors in the JDO Expert group. They have got their win by putting the JDO spec out of the J2EE spec, do the really need to publicly humiliate the JDO users further by making a working spec and existing products not accepted by the JCP, even though it is not within the J2EE spec? Bizarre...

    Don't they realise that these JDO users in many cases also uses their J2EE producst anyhow (hence paying for the licenses), and therefore also publicly humiliate their own licensees? Especially odd, also because they (the J2EE vendors) won't have a working soulution for POJO persitence in a few years yet. It looks like the J2EE vendors really are making an effort to show arrogance towards their customer. Don't really know why.

    A very frustrated J2EE and JDO user
    Johan Strandler
    Smart Connexion
  174. JCP is Flawed (not my assertion)[ Go to top ]

    I think it's wonderful that Robin Roos and all other involved have the energy and will to make JDO 2.0 through the JCP. Kudos for that!

    I second that.
    But, if these 4 weeks will end up in a new No-vote again...

    I don't think a no-vote is the only bad outcome. I would personally be deeply unhappy about the situation if the JDO 2.0 spec was substantially cut back in order to meet the concerns of J2EE vendors and future implementors of the EJB3.0 POJO API.
  175. if these 4 weeks will end up in a new No-vote again, I tend to appreciate Steve Zara's view that the real JDO vendors should go for their own "JCP" route, perhaps in cooperation with Apache

    I completely agree.

    And looking at the last Ballot, the next will be the same , I see no reason for a change of direction in IBM & Oracle(their assault is done):

    All vendors :Solarmetric, Versant ,Xcalia, Apache , etc. should start joining efforts for their own "JCP" route , a lot of users including me will appreciate it.

    Remember that the community is more powerfull than companies desires... and the community supports JDO.
  176. JCP[ Go to top ]

    Many stakeholders have an interest in a technology. Some of them write the spec, some implement the spec, some user the implementations, some educate the community, some merely observe and occasionally contribute to the debate. All of this makes the debate healthy. This is how it should be.
    This is absolutely true. In most cases the different kinds of member reps are sought for and encouraged to ensure that different perspectives are present. This increases the likelihood that the end result will be a successful one.
    My only regret about the membership of JSR-243 is that Gavin King (Hibernate) and Mike Keith (Oracle) chose to leave.

    Just to clarify, I didn't wake up one morning, put on my Pokemon slippers and say to myself "Today I think I will leave JSR 243" (well, okay, so the part about the Pokemon slippers may have happened). Oracle felt that EJB 3 was the best way to standardize lightweight POJO-based persistence within J2EE.

    Oracle is one of the biggest J2EE supporters and licensees, so it clearly made more sense to pursue this within the J2EE specification. Obviously I personally didn't make the decision (or I would be asking for more money) but if it was my call I am sure that I and any other reasonable person would have made the same decision.

    Note that this is not about which technology is better because from experience I know that there are just as many smart people working on the JDO group as there are on the EJB group.

    It isn't about how soon one spec gets released over the other either because I think they only differ by a few months and in specification time that is negligable.

    I can't speak for others, and in fact I can't really even speak for Oracle, but for me it is simply about eventual convergence of the persistence community within J2EE. Period. My dream is that JDO and SolarMetric customers, TopLink customers, old EJB customers, Hibernate customers, and any other persistence customers are able to move to a common persistence spec that offers the basics of what most people need. I don't think that it needs to have every single feature known to persistence developers, because that will only convolute the spec and limit who can implement it. More deluxe products can add value as customers require it, and as the bar gets raised over time then the spec can adopt them.

    Anyway, I see now that this is turning into a treatise, and I should just blog it instead of blathering on about it here, but anyway, there it is.
    To Mike: belated congratulations on 10 years of TopLink persistence, and apologies for not having said so sooner.

    Thanks. Sorry about the misunderstanding on that thread (I clarified it here). I expect an invitation to SolarMetric's 10-year party when it happens ;-)

    -Mike
  177. 10-year anniversary[ Go to top ]

    I expect an invitation to SolarMetric's 10-year party when it happens ;-)

    Mike, it wouldn't be a party without you. Consider it done. Block off August 7 2011 on your calendar.

    -Patrick

    --
    Patrick Linskey
    Kodo JDO
    http://solarmetric.com
  178. Nice Positive Tone[ Go to top ]

    There are no JDO expert group members which I believe should not be members.

    Nice happy talk, but please explain to me why hardware vendors like Nortel, Fujitsu, HP, and Intel are deserving of Expert Group status?

    Please explain why firms with competing products and products that would be commoditized (db vendors) are valuable members?

    How much input/effort from the Expert Group is in the spec itself?
  179. Nice Positive Tone[ Go to top ]

    There are no JDO expert group members which I believe should not be members.
    Nice happy talk, but please explain to me why hardware vendors like Nortel, Fujitsu, HP, and Intel are deserving of Expert Group status?Please explain why firms with competing products and products that would be commoditized (db vendors) are valuable members?How much input/effort from the Expert Group is in the spec itself?

    We are talking about 2 different groups of people.

    The expert group are the ones that wrote the specification, you can see how they are on http://www.jcp.org/en/jsr/detail?id=243

    But the ones that voted NO, are the the Executive Committee they are listed on http://www.jcp.org/participation/committee/index.jsp#SEEE



    Cheers
      JD
  180. Oh give me a break![ Go to top ]

    Now this has got to be one of *the* most idiotic and misinformed threads I have *ever* seen on TSS. And that's saying a lot. Most of the commenters here are prepared to smear people and companies with absolutely zero knowledge of JCP procedures, timetables, agreements that have been made between different groups, or the motivations of the people they are smearing.

    In future, please try to educate yourselves before spewing nonsense on public message boards.

    #1: A "no" vote means that most EC members have serious issues with the current draft submitted. It does NOT mean that there will never be any new JDO draft ever. It most certainly does nt many that any EC members feel threatened by the existence of JDO. On the contrary; AFAICT, most members who voted "no" are pretty much indifferent to JDO.

    #2: There will be an opportunity for the JDO EG to address the concerns of EC members, and resubmit. EC members are now actively trying to figure out exactly what changes could be made to the JDO draft in order to satisfy the concerns of all parties. This will almost certainly involve *negotiation*. That's what adults do, to resolve their differences. They don't smear people in public.

    #3: Members of the JDO and EJB3 expert groups agreed to work *together*. This involved undertakings from both sides, and means that both sides have had responsibilities to do certain things. It also means neither group will get *everything* they want. I personally hope that both groups are prepared to work together to make this agreement work. Posters in this thread should be encouraging those of us who are interested in working together to make this agreement successful - not encouraging zealots to quit the JCP and go it alone.

    #4: At the end of the day, the Java community will get, in Mike Keith's words "not two persistence specs, not zero, but one". And this spec will have the support of all credible vendors. If you want to help in this unfortunately messy situation, please encourage everyone involved to work together, and commit themselves to support for the single spec. This EC vote should be interpreted, AFAICT, as a vote of support for the notion of a single persistence solution that integrates with J2EE. It is a vote against the two EGs each going it alone, while paying lipservice to the notion.

    #5: I expect the EJB3 spec to be complete well before the end of this year, and useful, basically complete implementations to appear before the finally final draft. There has been an incredible amount of irresponsible FUD thrown around about the timetable of EJB3, and honest people should stop that now!

    #6: I am not an EC rep, but I so have some small influence over at least one EC rep. If Robin or anyone else on JSR-143 wants to contact myself, Sacha or anyone else at JBoss, to understand our concerns and lobby for our support for a revised draft, they are much more than welcome to. Indeed, I am very, very surprised that no-one has yet tried to contact JBoss to ask for our support.

    #7: I can assure everyone here that they are no "twats" sitting on the EC, as was claimed by Cameron Purdy. I can also assure everone that there were no sinister motivations involved.

    Regards,
    Gavin King
    Hibernate / JBoss Inc
  181. Oh give me a break![ Go to top ]

    It does NOT mean that there will never be any new JDO draft ever.Regards,Gavin KingHibernate / JBoss Inc

    So, what's needed then? drop all RDBMS features from the JDO spec for your amusement?
  182. astonishing[ Go to top ]

    It does NOT mean that there will never be any new JDO draft ever.Regards,Gavin KingHibernate / JBoss Inc
    So, what's needed then? drop all RDBMS features from the JDO spec for your amusement?

    Oh, what a great start. Insult me and put words on my mouth.

    What a fantastic way to win people to over.
  183. AFAIYCT[ Go to top ]

    AFAICT, most members who voted "no" are pretty much indifferent to JDO.

    The what on earth are they doing voting on it? For the benefit of the consumer?

    Quoting Carl - "I have to laugh"
  184. Oh give me a break![ Go to top ]

    Gavin,

    Please clarify why the supporters of JDO 2.0 should negotiate with those who do not support it? Can you honestly say that those who have been opposed to JDO for one reason or another have the best interests of JDO at heart? Likewise, why is it that the supporters of alternatives to JDO claim to have the only true insight into the needs of users?

    A lot of people have worked very hard to define JDO 2.0. The expert group has been open. You were a member for a while until you found other passions to pursue.

    I'm not saying that everyone has to support JD0 1.0 or 2.0, or use it. But why are those who oppose it refusing to allow those who favor it to use it?

    The answer is fear. Ben Eng in the note in this thread labeled "sabotaging JDO's market momentum" has provided a thorough analysis of the basis of that fear.

    I have been a member of the JCP for only a few years. The vote on JDO 2.0 was about the slimiest action taken that I'm aware of.

    If the JCP is to be salvaged from this self-inflicted wound, it will need to become more opensource like. Let those who do the work draft the standards, and let the market decide what they like and don't like.
  185. reread the letter[ Go to top ]

    Gavin,Please clarify why the supporters of JDO 2.0 should negotiate with those who do not support it?

    I think its pretty clear why there should be negotiation.

    http://java.sun.com/j2ee/letter/persistence.html

     
      Can you honestly say that those who have been opposed to JDO for one reason or another have the best interests of JDO at heart?

    I think it is clear from all the NO votes above that this is a mandate for a unified specification. The NO votes care about a unified specification.

    Again, the JDO experts were invited to participate in JSR 220 back in September and they have. Both teams (JDO/EJB) are ALREADY working together to complete JSR-220.
    "sabotaging JDO's market momentum"

    Embracing a unified specification can only increase JDO's market momentum. The combined market of EJB/Hibernate/Toplink/JDO is a lot larger than than any one individual specification or product. Cooperation will make a JCP-based persistence specification strong and stop the fragmentation and divisivneness that has been ongoing for years with the dual-specs that are present now.

    Bill
  186. JSR 243 Goal[ Go to top ]

    As currently planned, the scope of JSR-243 will include maintenance to JDO 1.0.1 and enhancements to JDOQL.

    If this is achieved why the no vote?
    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.

    Since JSR 220 and the 'POJO persistence model'/'new common persistence api' is not approved and won't be until next year this aim is not possible to meet. I guess JDO 2 will have to wait for the rest of the EJB3 spec to be completed and by that time the big players will be positioned to not lose market share.

    I get sick to my stomach watching this farce and waiting for a usable persistence specification.

    The politicians and big oligopies can take a flying leap, and Apache/Open Source has another winner.
  187. Rose colored glasses[ Go to top ]

    The NO votes care about a unified specification.

    I'm sure some of the NO votes care about a unified specification. But some care about an ALTERNATIVE specification, and they don't want any JDO spec done before theirs is done.
    Again, the JDO experts were invited to participate in JSR 220 back in September and they have. Both teams (JDO/EJB) are ALREADY working together to complete JSR-220.

    No. A few (6 out of 40 or so) JDO experts were invited to participate. The rest were told that their help would not be needed. There are no TEAMS working together here.

    Finally, if this was a question of cooperation, then we would see them saying "fare thee well" instead of "over my dead body." In fact, the letter that you reference states that JDO 2.0 should go forward. But some of the NO vote comments indicate strong doubts whether JDO 2.0 should even exist. In essence, if they subscribed to the views of the letter and voted NO, they have reneged on the understanding embodied in the letter.

    The supporters of JSR 220 want JDO 2.0 to wait for JSR 220 and then embrace the one true persistence service, a.k.a. UPS or unspecified persistence service. But JDO 2.0 is 12 to 24 months ahead of JSR 220. JDO 2.0 is nearly done, and that in the nutshell is the problem. Obstruction is the goal of the naysayers. Negotiation is their cover.
  188. reread the letter[ Go to top ]

    I think it is clear from all the NO votes above that this is a mandate for a unified specification. The NO votes care about a unified specification.Again, the JDO experts were invited to participate in JSR 220 back in September and they have. Both teams (JDO/EJB) are ALREADY working together to complete JSR-220.


    As you say, both teams are working on JSR 220. And from what I've read, relational JDO vendors have pledged to support 220's APIs in addition to the JDO 2 APIs. JSR 220 is alive and well and slated for early 2006. So why the need to deny the community JDO 2 now? How does rejecting something users want benefit the community?

    By all accounts JDO 2 is a very good spec. It exactly meets the goals it stated in JSR 243. All the added features were driven by users. And it's pretty much complete! The spec is at final draft stage; JDO vendors are already offering JDO 2 preview features; the JDO community in particular and persistence users in general are chomping at the bit to use the new functionality; the open source community has agreed to tackle the RI and TCK. The *only* thing stopping JDO 2 is a few "no" votes from companies that either offer competing products or don't play in the Java space at all. So how are we supposed to see this vote as motivated by anything but politics?

    The bottom line is that JDO 2 benefits users, and harms no one. It doesn't magically stop work on JSR 220. It doesn't confuse users any more than the continued survival of JDO 1, iBatis, Hibernate, and JDBC will confuse users after JSR 220 is released. The only possible entities it harms are EJB vendors who don't want competition, as the vote makes obvious. If JDO 2 doesn't pass or is lobotomized, it will be a sad day for the JCP. It will be a statement that politics matter more than good technology and the good of the Java community.

    That said, I don't think it will kill JDO. JDO has a strong user base, nice tech, and vendors that seem to be able to cooperate when necessary. It also provides an excellent POJO persistence migration path to JSR 220. But even if JDO continues stronger than ever, my faith in the JCP will remain shaken.
  189. NO NEED for EJB3[ Go to top ]

    At this point I´m totally disappointed with this kind of unification between EJB3 and JDO2.

    I really think, that we don´t need to throw away the best Persistent Framework in the world (JDO).

    I also don´t think that every JDO implementation will throw away its code and thowsand of hours of work(and money) and... the most important thing:
    Every JDO implementation has its customers already.
    Changing the Framework will mean , for all these companies to lose their actual clients because every client will start evaluating all EJB3 implementations but with JDO Framwork they already have established reputation.

    Finally: There has been years of training programmers in JDO (and a lot of money ).


    JDO IS THE BEST PERSISTENCE FRAMEWORK ---- REALY, NO NEED FOR ANYTHING ELSE
  190. reread the letter[ Go to top ]

    It doesn't confuse users any more than the continued survival of JDO 1, iBatis, Hibernate, and JDBC will confuse users after JSR 220 is released.

    It's probably very obvious that I am a strong supporter of JDO, and I am very unhappy about this decision.... however, I can to some extent understand the confusion argument. JSRs are intended to be recommended specifications. Overlap between JSR 220 and JDO 2.0 could well confuse users. iBatis, Hibernate etc. aren't intended to be standards, JDO 2.0 and EJB3.0 are!

    I think that the intention for a single POJO persistence standard is misplaced. JDO 2.0 could be positioned as a general-purpose datastore-type-agnostic specification, and the EJB3.0 POJO positioned as a specification optimised for use in J2EE with EJBs and recommended for that purpose. After all, who wants datastore-type-agnostic persistence for EJBs! That situation is almost always going to involve RDBMSes. Sun has many parallel specifications indended for different purposes: J2ME and J2SE for example.
  191. #6: I am not an EC rep, but I so have some small influence over at least one EC rep. If Robin or anyone else on JSR-143 wants to contact myself, Sacha or anyone else at JBoss, to understand our concerns and lobby for our support for a revised draft, they are much more than welcome to. Indeed, I am very, very surprised that no-one has yet tried to contact JBoss to ask for our support
    Regards,Gavin King Hibernate / JBoss Inc

    Looks like this "contact" with Hibernate and JBoss is crucial for the outcome of the next vote?

    I wonder if it was the lack of this "contact" which caused last draft to fail?
  192. Oh give me a break![ Go to top ]

    Gavin,

    You have valid points - there should be more collaboration between JDO 2,0 and EJB 3.0. I think most of the ire comes from the premise the EC members used to vote against this JSR.

    How can writing an Open Letter to the community change the direction and the original stated goals of a JSR considering most developers don't care about aligning JDO 2.0 with EJB3?

    This spec is supposed to meet specific issues. I certainly don't care to wait until EJB3 finally comes out "later this year"!

    Regardless of the votes outcome, it really doesn't look good for any company that _may_ have conflict of interest issues - maybe you guys should have abstained instead.

    I know I feel like I've been flogging a dead horse with JDO. It may be time to move along and have another look at Hibernate. ;) or OJB.

    Cheers,
    Oz.
  193. Oh give me a break![ Go to top ]

    This EC vote should be interpreted, AFAICT, as a vote of support for the notion of a single persistence solution that integrates with J2EE.

    Ok, I think I found the solution to this: everybody vote yes, let JDO 2.0 go to production, as there is no technical motive not to, and have EJB3 JSR group use JDO's API as a reference, and any standing differences or needed adaptations found during EJB3's JSR works result in the creation of JDO 2.1, which then would be _the_ unified persistence API. This would actually help EJB3 adoption, since when EJB3 becomes reality, there will already be lots of JDO2.0 frameworks and POJO based systems out there, making it a breeze for people to move on to EJB3 (which is not just about persistence, BTW). Besides, having EJBs got such a bad name lately mainly because of its persistence mechanism, switching it for a neutral one would increase even more its chance of success. The only problem I see is the backward compatibility with EJB 2.1, but since there are already existing EJB frameworks using JDO to provide persistence, maybe this won't be such a huge problem to solve.

    If what I've just written above is pure crap, feel free to ignore me.

    Regards,
    Henrique Steckelberg
  194. From the masters...[ Go to top ]

    There has been an incredible amount of irresponsible FUD thrown around about the timetable of EJB3, and honest people should stop that now!

    Do my eyes deceive me, Gavin, or is an employee of JBoss, Inc actually decrying the spreading of FUD on the forums of TSS? It seems to be not too long ago that you people were caught with your pants down making up fake personalities to pretend there was support for your products and spreading misinformation about competing products (see the expose). Your self-righteous lecture about "FUD spreading" is more than just a tad hypocritical, no?

    Why on earth should anyone believe anything that you say?
  195. Your self-righteous lecture about "FUD spreading" is more than just a tad hypocritical, no? <
    Dear "Salim",

    Please point to a single example of myself or any other member of the Hibernate team "spreading FUD", or posting under a "fake personality".

    Oh, so no specific examples?

    OK, well, back to your hole, then. :-)
  196. From the masters...[ Go to top ]

    Salim: Do my eyes deceive me, Gavin, or is an employee of JBoss, Inc actually decrying the spreading of FUD on the forums of TSS?

    AFAIK - Gavin absolutely deplored the astroturfing when he found out about it, and he had nothing to do with it.

    Gavin: Please point to a single example of myself or any other member of the Hibernate team "spreading FUD", or posting under a "fake personality".

    Honestly, I'd qualify several (several!) statements made by EJB3, JDO2 and Hibernate members as FUD. Remember, one man's marketing is another man's FUD.

    Look, JDO (including JDO2) is a very workable solution. I've witnessed it. It sure beats any of the persistence standards that came before it (i.e. EJB prior to EJB3), and it sure beats using a 100% non-standard product (now that it is purposefully so) such as Toplink.

    Hibernate is a very workable solution. I've witnessed it. It sure beats any of the persistence standards that came before it (i.e. EJB prior to EJB3), and it's free which is an awful hard price to beat.

    EJB3 will hopefully be a very workable solution. Having you and members from the JDO group in there, plus a pre-existing realization from the EJB group of the flaws of EJB1+2 for persistence should almost guarantee a major improvement.

    However, if there's something wrong with JDO2 spec, including the potential that the choices made in it will "sabotage" (for lack of a better word) the future standardization of an ORM (spec+API) that could go beneath both EJB and JDO, then those specific issues need to be itemized, not alluded to. (Alluding to such things is just a form of FUD, is it not?) Otherwise, to vote against the JSR would require that it failed to meet (or it failed to be contained by) its mandate that it was originally given, or it failed in a gross technical manner, or that there is no use any longer for the JSR -- which is obviously wrong since there are users of JDO begging for JDO2 to complete.

    That's my $.02 anyhow .. and to someone, it is no doubt FUD ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  197. Please, give "ME" a break...[ Go to top ]

    If I we're in your shoes I would certainly hope that JDO goes away asap. It's not a critique but if there is one person that has vested interest in seing JDO disapear it is you and all the EJB vendors.

    Again, it's just an observation. If I had written a data persistence framework and gave it away to a sudo open source commercial company that also has all the reasons to not support JDO, I too would have voted NO on JDO 2.0.

    I think that the JBOSS group is now becomming more a nuisance than a benefit to the open source movement and to all java developers. We can now see that the commercial self interest of the JBOSS group comes before any of the communities that supported them in the past.

    I hope that Apache will step up and take JDO under it's umbrella, If they do I am ready to invest time and even money to make sure that all "free" developers can have what they need and not what Big Brother (aka j2ee vendors) tells us we need.

    Ok, that's enough... Good night...;--)

    Patrick
  198. Vendors not thinking of customers interests ?[ Go to top ]

    Hi,

    I work for a customer who already has a big investment in a JDO based database layer. I wreckon that are not the only one. One of the reasons they chose JDO over a proprietary solution was more stability, because of not being dependent on one vendor.

    This argument for using JDO is now completely undermined by companies with a different agenda. JDO's future is suddenly uncertain. I see two solutions to this, the first one is probably not very realistic, but anyway:

    1) JDO users should make it clear to NO voting JCP members that they are also customers of, that their actions are _not_ appreciated. Something along the lines of

    'Could you please leave the JDO expert group or just vote yes, as you do not provide any persistence solution yourself and endanger the long term viablility of a product that we invested money in - if not we will have to switch to another application server vendor'.

    2) Members from the expert group that actually have working software and contribute something useful could think about another platform than the JCP to further the JDO standard.

    There might be big advantages to this, like a faster proces. No offense, but the JDO process is going _way_ too slow. The effect is that to get any real work done we are relying on 2.0 preview features for about a year now already !

    As a side note, I don't see any real business value in having one uber standard for all Java persistency. JDO is there, is good enough, now let's get back to work and build some useful applications for our end users.

    Cheers, Luc.
  199. Gosh[ Go to top ]

    Gosh – I've read some amazingly daft stuff on TSS (much of it written by Rolf) but my jaw hit the floor as I started to read through this thread. Screaming, shouting, hurling abuse and yelling "conspiracy" – getting on like a house on fire basically.

    The bringing together of EJB and JDO is something that is desperately needed in the J2EE world and something which many people on TSS and elsewhere have been calling for for a while. It is in hand after years of wrangling, and this is a very good thing. It is simply irresponsible to try and push through another spec which may conflict with the EJB3 API at this point. Take a deep breath, wait for a few weeks, iron out the conflict problems and resubmit the proposal having addressed these concerns. Oh and for goodness sake grow up a bit.

    Sorry to be so grumpy, I've had a difficult week.

    Fred
  200. Gosh[ Go to top ]

    It is simply irresponsible to try and push through another spec which may conflict with the EJB3 API at this point.
    May I rephrase it, just so we get a glimpse of what ir really happening now:
    It is simply irresponsible to try and push through another spec which may conflict with the JDO API at this point.
    JDO exists now, works now, is ready now. So why should JDO change for the sake of something that doesn't exist now, doesn't work now, isn't ready now? EJB3 will still have to prove itself, long after JDO 2.0 should be already done and proven and stablished. Why warp something that works, for the sake of something that is still being developed and not set in stone yet? Why waste precious time recreating something that exists? Why not focus instead on improving things that don't clash with the already existing persistence spec, like remoting, clustering, messaging, etc, etc, etc?

    Regards,
    Henrique Steckelberg
  201. The proof is in the pudding[ Go to top ]

    EJB3 will still have to prove itself...

    Yes, and what has the crowd that produced EJB 1.0, 1.1, and 2.0 done in the past that gives anybody confidence that they will get POJO persistence right in the future? They didn't even understand the need for it until JDO and other persistence services starting leading developers off the reservation. Now suddenly, they are our self-appointed leaders, the all-knowing ones who will define the one true persistence service. Yeah, right! That's the story!

    They may do a good job. They may even do a better job. But at the moment we are being asked to take this on faith. There is no evidence, and they are late, and I suspect they are going to be later still.