JDO 2.0: Lots of changes discussed at the kickoff meeting

Discussions

News: JDO 2.0: Lots of changes discussed at the kickoff meeting

  1. Last week there was a JDO 2.0 kickoff meeting (as posted on TSS). Since this meeting was a pre-JCP thing, everything that was done/said is public, and hence I could release this report on the event. The report discusses the feel of the meeting, and goes into details on the technology that is going to try to get into JDO 2.0.

    For example,

    - JDO/R: O/R mapping standardization
    - Query updates: Enhanced JDOQL, SQL support, named queries and more.
    - Detach/Attach API

    As the report states, I was very impressed by how the meeting went. The vendors were not acting against eachother, but rather together. Four of them got together in a sub-group to work on the O/R mapping side of things, and worked into the night on it, giving eachother a lot of insight into their own systems. I am very excited about JDO 2.0 now.

    Read: JDO 2.0: Lot's of changes discussed at the kickoff meeting

    Threaded Messages (55)

  2. JDO Genie link incorrect[ Go to top ]

    The link for JDO Genie is
    http://www.jdogenie.com

    The HTML source is missing an "http:/".

    Thanks Dion for the writeup!
  3. Fixed :)[ Go to top ]

    Thanks for spotting that David.

    I fixed it in the doc. Was nice meeting you last week.

    Dion
  4. Hibernate involved?[ Go to top ]

    So is Gavin King and Hibernate involved in JDO 2.0? Hibernate is just too cool of an open source project to be ignored and just have way to much great functionality to not be involved with the process.

    Hans
  5. Oracle & SAP?[ Go to top ]

    The article mentions "a couple of small companies you may know: Oracle and SAP".

    Does this mean they will be releasing JDO compliant products. In particular will Oracle's TopLink be JDO compliant?
  6. I hope so :)[ Go to top ]

    I can't speak for these guys, but the people they had at the meeting were great. At the beginning of the meeting, a VP at Oracle gave a presentation on how he feels TOPLink fits into things, and that they ARE interested in being a JDO vendor. They had a couple of issues (e.g. they use a reflection-based approach so need to be able to be spec-compliant with that), but I would hope that they are onboard, as long as nothing drastic changes.

    Dion
  7. I hope so :)[ Go to top ]

    I can't speak for these guys, but the people they had at the meeting were great. At the beginning of the meeting, a VP at Oracle gave a presentation on how he feels TOPLink fits into things, and that they ARE interested in being a JDO vendor. They had a couple of issues (e.g. they use a reflection-based approach so need to be able to be spec-compliant with that), but I would hope that they are onboard, as long as nothing drastic changes.

    >
    > Dion

    Dion, I heard you were on the committee. Where is Gavin King? Can you get Hibernate involved? We've been using Hibernate for awhile now and it seems to plug a lot of the holes that are in the current JDO specification. There user community seems to be growing quite large and they really shouldn't be ignored.

    Hans
  8. Gavin King[ Go to top ]

    Hans -

    I mentioned this a little in my report. I *personally* would love to have Gavin on the expert group. Hibernate is a top quality product, and Gavin is a very smart guy. I think it could benefit both Hibernate and JDO in general if he was involved.

    We brought up this fact, and Craig said that he had invited Gavin, but from Gavin's comments on another TSS thread, I think that he didn't get that email. I am sure that Craig will be contacting Gavin ASAP to get him in the loop.

    I do want to make sure that you know that Hibernate isn't being ignored at all. Not only do we want a representative on the expert group, but we also talked about how we could align ourselves with some of the things that they do, in the hope that we can join forces.

    Dion
  9. Gavin King has been invited[ Go to top ]

    Hi Dion,

    Great to meet you at the kickoff meeting. The times they certainly are a changing!

    I'm cross posting this note that I attached this morning to the other kickoff thread:

    Yesterday, Craig Russell extended by e-mail a cordial invitation to Gavin to participate in the JDO 2.0 specification process. Not surprisingly, I have not yet heard Gavin's response. Like all members of the current JDO expert group, I hope it will be positive.

    David
  10. Re: Gavin King has been invited[ Go to top ]

    I've exchanged emails with Craig Russell finally, and agreed to participate in the JDO2 effort. To clarify, my objections to JDO have always been strictly technical and I have no great objections to standards per se. I'm much more concerned by Bad "standards" being forced down user's throats.

    It looks like many of the the proposals for JDO2 really address my biggest problems with the JDO1 spec, so, in future, we might be able to provide a JDO2 interface alongside the native Hibernate API. There will continue to be great value in our native API, since it is concerned with exactly one problem (ORM) - but for people who desire portability, JDO has value.

    In particular, the proposal to remove the requirement that POJOs implement PersistentCapable means that systems like Hibernate and TopLink would be able to comply with JDO without needing to rebuild from scratch. This means we can concentrate on delivering user-visible features.

    Gavin
    http://hibernate.sf.net
  11. Re: Gavin King[ Go to top ]

    I do want to make sure that you know that Hibernate isn't being ignored at all. Not only do we want a representative on the expert group, but we also talked about how we could align ourselves with some of the things that they do, in the hope that we can join forces. <

    I thought "this looks like JDO 1.0 plus Hibernate's more important features, good" while reading your report. Great work. :)
  12. Re: Gavin King[ Go to top ]

    Just stop wasting time and invite Gavin from Hibernate and Alex from JBossDO, who has a JDO implementation to the table. And even better, why bother with all the time spent on a spec, use Hibernate as the specification and go from there...This seems like a good idea to me, but perhaps I am crazy. What is the reality, the spec will become final in like 1.5 years and then we will already have something better that we need a spec for. Start with something that works, an implementation and then work from there.
  13. "j2ee master", there are already many implementations of the JDO 1.0 spec. See http://jdocentral.com/JDO_Links_Body.html#readup4 and http://jdocentral.com/JDO_Links_Body.html#readup15

    Why bother with a spec? Because that is what I would think most users/developers want. We dont want to be tied into a persistence mechanism. A spec will allow one to move freely from one implementation to another, or even use different implementations depending on the task at hand.

    Hibernate for example is no good if I want to use a datastore from an object database vendor.

    Cheers,
    Menno
  14. Re: Gavin King (don't bug him)[ Go to top ]

    Just stop wasting time and invite Gavin from Hibernate ... And even better, why bother with all the time spent on a spec, use Hibernate as the specification and go from there...


    In one year Hibernate has come out of nowhere to threaten several JDO vendors who've been grinding their noses on the JDO spec for over two years. How can this be? Perhaps it's because Gavin King knew what to leave out. Binding data to a Plain Old Java Bean with Plain Old Reflection means he didn't have to re-invent data binding and then struggle to decouple it from a PersistenceManager. If I don't use an OODBMS and I can deal with an RDBMS then I don't want JDO + Hibernate. Please don't waste GK's time on spec meetings!

    In a simpler world JDO would just be a Strategy and Hibernate would be its Concrete Strategy for O/R persistence.
  15. As an earlier poster mentioned, the scope of the JDO 2.0 specification is broader than just O/R mapping -- which Hibernate is a particularly effective implementation of, by all accounts (though you'd have to ask the JDO vendors if they feel particularly threatened by Hibernate -- from my discussions with them, everyone was eager to have Gavin involved). The concept of transparent persistence is datastore independent, which means that the long-term persistence of your object model can work whether your back end is a relational database, object database, XML file, or host of tiny angels dancing on pins.

    As developers, we're all free to use whatever software we want, whether or not it implements an official JSR-blessed API. JDO has proven itself to be a highly useful technology and API; so has Hibernate. Because their goals are often closely aligned, it seems to make sense to create something in JDO 2.0 that standardizes and legitimizes the best practices of both transparent persistence and object relational mapping.

    Wes
  16. Guys, why don't you just make it easy on yourselves and annoint Hibernate as the JDO 2.0 standard? Instantly you get a robust reference implementation.

    However, guess what's going to happen, you're all going to debate for 1.5 years, discussing completely irrelevant issues, by that time Hibernate would be at version 3.0 and JDO vendors would be stuck at 1.0 with comletely incompatible extensions.

    My opinion, the TopLink and Hibernate are the two groups that can add any true value to the table. Everyone else, will just add to the noise.
  17. Oops, I forgot BC4J which actually is equally cool.
  18. Hello Everyone

    Here are a couple of comments from earlier emails to which I'm replying...

    Carlos Perez:

    > Guys, why don't you just make it easy on yourselves and annoint
    > Hibernate as the JDO 2.0 standard? Instantly you get a robust
    > reference implementation.

    j2ee master:

    > Just stop wasting time and invite Gavin from Hibernate and Alex
    > from JBossDO, who has a JDO implementation to the table. And even
    > better, why bother with all the time spent on a spec, use Hibernate
    > as the specification and go from there...

    Carlos Perez:

    > My opinion, the TopLink and Hibernate are the two groups that
    > can add any true value to the table. Everyone else, will just
    > add to the noise.

    Ok, here goes:

    Why would we want a robust reference implementation? The community seems to have been star struck by Tomcat, the RI for the Servlet spec, which is also a very fast and robust web container suitable for commercial deployment. But that is one special case. The only requirements for an RI are to (a) show that the spec is implementable, and (b) clarify the "correct" behaviour in any given set of circumstances. Robustness, performance and scalability just don't come into it.

    Now, coincidentally we will need to provide a JDO 2.0 reference implementation which is capable of exhibiting the O/R mapping aspect of the standard. The JDO 1.0 RI does not even target JDBC datastores, and it is more plausible to choose an alternative "product" to be the RI than to engineer the JDBC aspects into the current RI. The result might be a stable RI which is capable of commercial deployment, but that would be a side-effect and not a core objective. Furthermore there is an ideology issue around having RI's which are that good, since being the RI affords additional marketing collateral to one particular implementation in a field of competing implementations. But that's enough on that topic for now....

    Everyone is talking about Gavin King in these threads, except for Gavin himself. I tried unsuccessfully to contact him prior to the JDO 2.0 Kick-off Meeting to solicit his attendance, and I'm sure others did as well. Subsequently it has been made clear to Gavin and to the community that he would be a welcome member if he wishes to participate. Gavin's membership of the JDO 2.0 Expert Group is not necessary for Hibernate to implement the JDO spec, but neither should the community presume that JDO-compliance for Hibernate would be Gavin's intention if he did decide to join. Perhaps it would be best if we all (myself included) stopped talking about him in his absence, and concentrated on the issues at hand: the groundswell of momentum behind JDO, the JDO 2.0 feature set, and the similarities and differences between JDO and Hibernate.

    I'm glad that Carlos sees TopLink as a valuable contributor to JDO, particularly since the TopLink team was represented admirably at the meeting by a representative from Oracle&#8217;s (TopLink's) Ottawa office.

    Kind regards, Robin.
  19. Let's all not get confused as what really is important.

    What really is important is that Java needs a common standard for doing O/R mapping.

    Nobody is demanding a common standard for OODBMS, afterall, how many of them exist in the marketplace today?

    Now, Hibernate folks are pretty focused in this goal, JDO, well you don't really know what the hidden agenda is. The original hidden agenda, although it wasn't hidden when it was first proposed, was to support OODBMS. For some strange reason the message was hijacked and now its supposed to be the "data" standard.

    So, let's be fair to all those participating, what *exactly* is the objective? Is it some nebulous Java "data" standard, or is it the best damn way you can do O/R mapping? I would love to have a Java O/R mapping standard, I would not like to have it poluted by concerns that have don't exist in reality.

    My point is that you can't really invent new technology is a commitee, you can't try to solve a problem that is overly vague. What you can do is address an existing problem and standardize the solution with existing technology. Standardization committees are simply no place for invention.
  20. JDO == Transparent persistence[ Go to top ]

    Carlos wrote:

    "What really is important is that Java needs a common standard for doing O/R mapping.

    Nobody is demanding a common standard for OODBMS, afterall, how many of them exist in the marketplace today? "

    Maybe that is what is important to you. To me it is important to have transparent persistence. The message was not "hijacked" as you say. The goal is quite clear, at least to me from reading the JSR-000012 JDO spec. It is not to only do O/R mapping.

    I dont understand why you are not interested in transparent persistence, but dont assume that because you are not, nobody else is.

    If we have a good JDO spec then it will be possible to have true transparent persistence, where you can swap in any JDO implementation as you wish, using any datastore you please. Using a JDO implementation and find it's to slow at a certain thing that is critical to your app, just try Toplink/Hibernate(assuming they will be JDO compliant in the future of course), Kodo, Genie, XORM, etc. Need more speed than that, fine try an OO datastore from FastObjects or Versant.

    Cheers,
    Menno
  21. Common O/R mapping needed[ Go to top ]

    Hi Carlos

    "What really is important is that Java needs a common standard for doing O/R mapping ... My point is that you can't really invent new technology is a commitee ... What you can do is address an existing problem and standardize the solution with existing technology."

    This is exactly what the JDO/R part of JDO 2.0 is going to address. All the O/R mapping JDO vendors already have meta data to map to databases. They have all already solved parts of the problem in very similar ways and JDO/R will standardize the terms and meta data used. So "flat" inheritance using a "descriminator column" will be standardized in JDO/R (both meaning and meta data). Nothing new is going to be invented.

    In our meetings last week there was very little disagreement among the JDO O/R vendors present over what should be in JDO/R and what the meta data should look like. This is not surprising really as O/R mapping problems and solutions are well known. JDO vendors did not have to invent this stuff.

    Cheers
    David
  22. Wake up call.....[ Go to top ]

    Robin Roos wrote

    > Ok, here goes:
    >
    > Why would we want a robust reference implementation? The community seems to have been star struck by Tomcat, the RI for the Servlet spec, which is also a very fast and robust web container suitable for commercial deployment. But that is one special case. The only requirements for an RI are to (a) show that the spec is implementable, and (b) clarify the "correct" behaviour in any given set of circumstances. Robustness, performance and scalability just don't come into it.

    Are you serious? What do you do for a living? Most specs that are vague and abstracted get less use in the field, as they have too many competing implementations and thus lose the value of a standard.
    >
    > Now, coincidentally we will need to provide a JDO 2.0 reference implementation which is capable of exhibiting the O/R mapping aspect of the standard. The JDO 1.0 RI does not even target JDBC datastores, and it is more plausible to choose an alternative "product" to be the RI than to engineer the JDBC aspects into the current RI. The result might be a stable RI which is capable of commercial deployment, but that would be a side-effect and not a core objective. Furthermore there is an ideology issue around having RI's which are that good, since being the RI affords additional marketing collateral to one particular implementation in a field of competing implementations. But that's enough on that topic for now....

    If the RI is good and stable, it kills tha market, what is so wrong with having a FREE implementation of a spec? You can do this on your own anyhow. How many JDO vendors have come and gone? Many. Why? Because the first spec was not effective, as it was not based on real world stuff. If we all keep real world implementation in mind when we write specs, like implementation before specification, we will be much better. Maybe we should try and write the specs going forward, not as specs, but as best practices. If you are trying to solve this problem, use this specification. Instead of all this pie in the sky stuff, which takes too long and under delivers.
    >
    > Everyone is talking about Gavin King in these threads, except for Gavin himself. I tried unsuccessfully to contact him prior to the JDO 2.0 Kick-off Meeting to solicit his attendance, and I'm sure others did as well. Subsequently it has been made clear to Gavin and to the community that he would be a welcome member if he wishes to participate. Gavin's membership of the JDO 2.0 Expert Group is not necessary for Hibernate to implement the JDO spec, but neither should the community presume that JDO-compliance for Hibernate would be Gavin's intention if he did decide to join. Perhaps it would be best if we all (myself included) stopped talking about him in his absence, and concentrated on the issues at hand: the groundswell of momentum behind JDO, the JDO 2.0 feature set, and the similarities and differences between JDO and Hibernate.

    Perhaps, he is busy making his real life implementation better and not reading our rants....Just a guess.
    >
    > I'm glad that Carlos sees TopLink as a valuable contributor to JDO, particularly since the TopLink team was represented admirably at the meeting by a representative from Oracle&#8217;s (TopLink's) Ottawa office.
    >
    > Kind regards, Robin.
  23. Wake up call.....[ Go to top ]

    j2ee master:

    > If the RI is good and stable, it kills tha market, what is so wrong with
    > having a FREE implementation of a spec? You can do this on your own anyhow.

    Currently I know of 6 open-source projects building JDO implementations. In time all of these will probably be stable and robust, qualities which are not core to the RI.

    > How many JDO vendors have come and gone? Many.

    By my count 16 have come. I think two have gone, one of which was TechTrader. Remember them? Their implementation was purchased for an undisclosed sum by Solarmetric and rebranded as Kodo JDO....
  24. If the RI is good and stable, it kills tha market, what is so wrong with

    > having a FREE implementation of a spec?

    I don't think Robin was saying that there is anything wrong with an open-source (or otherwise free) implementation of the JDO spec. He simply pointed out that the goals of the reference implementation do not include all of the same goals of a product designed for enterprise use. In general, it is often true that the RI goals are pretty much a strict subset of an enterprise tool's goals, or at least compatible with the enterprise tool's goals, but this is not necessarily the case.

    In the JCP, the reference implementation is a part of the spec process, and it is therefore often useful for an RI to do things in manners that emphasize clarity to the reader over performance, scalability, or customizability / extensibility. So you may end up making different design and architecture decisions when writing an RI than you would when writing a spec. Let's take query parsing as an example -- the JDO RI might perform a slow but very understandable (to the code reader) parse of a query string, whereas a real-world implementation might optimize query parsing for speed (or space, when targeting small memory footprints) at the cost of code readability.

    I'm not saying that the RI should not be an open-source implementation (in fact, I think I lean towards saying it should be one). I'm simply pointing out that there are valid reasons why it is possible that an RI (open-source or otherwise) would probably not be exactly the same as a real-world implementation. In fact, if we (the JDO community) do end up with an open-source RI, I think it'd be likely that the commonly-used version of the product would be forked from (or an extension of) the RI codebase.

    -Patrick
  25. JDO/R[ Go to top ]

    By the way, for those of you asking how to reach the JCP members, you've seen about half of the folks at last week's meeting post in this thread over the past couple of days, so you can be fairly certain your ideas are being heard.

    Regarding JDO/R: one-to-one, one-to-many and many-to-many mappings will be required in JDO 2.0, as well as at least one form of mapping inheritance hierarchies to tables. As a bonus feature :-) there will be a standard XML schema to define the mapping. I think you'll find that this ends up looking very similar to what you've seen if used XORM, JDOGenie, Kodo, TopLink, or Hibernate in the past. As David Tinker said, we don't need to invent anything new -- Scott Ambler described the best practices for O/R mapping a long time ago. It's about time we had a standard way to describe that linkage in Java.

    Wes
  26. OJB[ Go to top ]

    I am very curious why Hibernate gets so much attention on these forums and OJB gets almost none. In this thread, in particular, I am curious about it as OJB at least has a JDO implementation!
  27. OJB[ Go to top ]

    I am very curious why Hibernate gets so much attention on these forums and OJB >gets almost none. In this thread, in particular, I am curious about it as OJB >at least has a JDO implementation!


    My guess is that they messed up with the choice of name. Like we need another acronym ? OJB ? OBJ ? confusing and instantly forgetable. Hibernate - different and memorable. Giving something a good name is important. Maybe the people at OBJBOBLOB (eh?) should do a re-naming exercise.
  28. OJB[ Go to top ]

    I am curious about it as OJB at least has a JDO implementation!


    Yep, but just a prototypical one, i.e. a plugin combo of the JDO RI and the OJB PersistenceBroker. They've announced an actually usable JDO implementation for OJB 2.0 (way to go). BTW, I'm curious how they will achieve that: OJB's kernel is reflection-based but JDO 1.0 requires the PersistenceCapable/StateManager approach.

    IMO, OJB's biggest problem is that its only usable full-power API is the ODMG one. And who really likes to work with ODMG? Hibernate on the other hand has a clear and powerful native API that is much nicer than ODMG... And of course, HQL is more powerful than OQL.

    Juergen
  29. If the RI is good and stable, it kills tha market, what is so wrong with

    > > having a FREE implementation of a spec?
    >
    > I don't think Robin was saying that there is anything wrong with an open-source (or otherwise free) implementation of the JDO spec. He simply pointed out that the goals of the reference implementation do not include all of the same goals of a product designed for enterprise use. In general, it is often true that the RI goals are pretty much a strict subset of an enterprise tool's goals, or at least compatible with the enterprise tool's goals, but this is not necessarily the case.

    Here in lies the problem with specs, if they are designed without enterprise class functionality in mind, what is the point. What is your point here? IS your point that specs are just that, paper, and then it is all about the implementation anyhow? IF this is the case, we will see M$ .net win, as they do not have a spec, they have an implementation. They start with an implementation designed with enterprise features, not a vague document that spawns 10 competing implementations. Do we really need 10 products that all do the same thing?
    >
    > In the JCP, the reference implementation is a part of the spec process, and it is therefore often useful for an RI to do things in manners that emphasize clarity to the reader over performance, scalability, or customizability / extensibility. So you may end up making different design and architecture decisions when writing an RI than you would when writing a spec. Let's take query parsing as an example -- the JDO RI might perform a slow but very understandable (to the code reader) parse of a query string, whereas a real-world implementation might optimize query parsing for speed (or space, when targeting small memory footprints) at the cost of code readability.
    >
    > I'm not saying that the RI should not be an open-source implementation (in fact, I think I lean towards saying it should be one). I'm simply pointing out that there are valid reasons why it is possible that an RI (open-source or otherwise) would probably not be exactly the same as a real-world implementation. In fact, if we (the JDO community) do end up with an open-source RI, I think it'd be likely that the commonly-used version of the product would be forked from (or an extension of) the RI codebase.

    Once again, I say if the goal of the JCP is not to create enterprise class specifications, what is the point, there is not point as people are always going to go above and beyond this anyhow. IMPLEMENTATION IS THE WAY. When you all agree on an RI, it will be irrelevant. Talk to you in about 18 months.
    >
    > -Patrick
  30. j2ee master: Do we really need 10 products that all do the same thing?

    No, of course not. We need a central planning committee that decides which the one true product will be. After all, having the market weed out the bad ones over time is wasteful of resources, as is competition in general. Even the fascists knew that a centrally controlled economy was more efficient than a free market.</sarcasm>

    If ten companies want to write a product in the same space, more power to them. If ten open source projects start to do the same thing, great! Maybe only two or three companies will survive and maybe only one or two of the open source projects will get to a reliable and feature-complete stage, but that's how our industry keeps surging ahead. Otherwise we'd all still be sharing time slices on a sluggish mainframe accessed through green-screen terminals and be paying tens of thousands for the privilege.

    Chaos rules, whether we like it or not. Fight it or surf it, it's your choice, but it makes no difference in the end ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  31. Quote of the day[ Go to top ]

    "Chaos rules, whether we like it or not. Fight it or surf it, it's your choice, but it makes no difference in the end"

    kind of sums up much of this discussion - very profound.

    Floyd, How about a TSS gallery of "quotes" - could be fun.

    Greg.
  32. "Do we really need 10 products that all do the same thing?"

    Fundamentally, this is a philosophical and economic question. Let me muse for just a little bit on this. If you have ever taken the opportunity to write a simple genetic algorithm that guesses the contents of any arbitrary string that you type in, you see some amazing behavior. Type in what you like, the Gettysburg address, or your favorite one-liner. Starting with random guesses, the genetic algorithm works towards the string that you entered knowing only two things: how close it is to the solution, and the alphabet of the string space. Within 400 or 4000 generations, every individual in the population "knows" the correct string.

    Software (among many other types of creative endeavors) shows this "we know it when we see it" quality. Evolution is messy, but it gets us to optimums. Do we need 10 products that all do the same thing? No, but we're not sure what the right thing is, and when we get there, we may discover that there is space for more than one kind of butterfly.

    :)
  33. Hey Carlos,

    "why don't you just make it easy on yourselves and annoint Hibernate as the JDO 2.0 standard?"

    Since you have decided that Hibernate is your standard, you don't really need anyone to validate that choice for you, do you?

    JDO is not for the suppliers of persistence layers, JDO is for the consumers of persistence layers. And you are quite right, not all consumers are concerned about avoiding vendor-lockin, portability, choice in implementations and vendors, delayed binding to the datastore architecture, etc. But for some, one or more of these factors are important considerations.

    The payoff to suppliers when they support JDO is the hope that a supported standard will grow the market more than would be the case when every vendor pushes their non-standardized solution. O/R mapping and other persistence layers have been around for some time. A great deal of invention has already occurred. Question is, do we want to standardize? I think the overwhelming sentiment is yes. Even you have mentioned areas that you would like to see standardized.

    Given the code reduction, design reduction, and feature acquisition permitted with any persistence layer, the use of a persistence layer that implements an accepted standard at reasonable cost and does the job well is a no-brainer for most development organizations.

    David
    :)
  34. Re: Gavin King (don't bug him)[ Go to top ]

    This implies that JDO vendors have been "grinding" on 1.0 spec features. Most of these vendors have features well beyond what Hibernate offers in terms of performance, flexibility, and usability. This is not to denigrate Hibernate in any way, but simply to point out the facts. There are plenty of open and closed source JDO efforts which are trying to standardize the parts of the persistence problem which Hibernate has "solved" which were solved in non-standard ways many years ago (TopLink, CocoBase, CMP, Wakesoft, Torque, hundreds of home-brew solutions), using a spec which allows for solving other parts of the problem better (e.g. state/field management, configuration, multiple datastores), and competing on the remaining parts (i.e. performance, usability, added features, etc.).

    > In one year Hibernate has come out of nowhere to threaten several JDO vendors who've been grinding their noses on the JDO spec for over two years. How can this be? Perhaps it's because Gavin King knew what to leave out. Binding data to a Plain Old Java Bean with Plain Old Reflection means he didn't have to re-invent data binding and then struggle to decouple it from a PersistenceManager. If I don't use an OODBMS and I can deal with an RDBMS then I don't want JDO + Hibernate. Please don't waste GK's time on spec meetings!
    >
    > In a simpler world JDO would just be a Strategy and Hibernate would be its Concrete Strategy for O/R persistence.
  35. More == Better![ Go to top ]

    Steve Lee writes
    >Most of these vendors have features well beyond what Hibernate offers in terms of performance, flexibility, and usability.

    I'll let others weigh in on performance, flexibility, and usability and I don't wish to denigrate all the talent and hard work behind JDO, much of the argument in this thread applies equally to any number of Java “Standards”. On side A are those who assume having “features well beyond” X is Good. On side B are those whose experience is that these extra features and broader scope complicate integration with components that have overlapping features. Side A assumes that the benefits of a standard are delivered by the JCP. Side B is increasingly skeptical about the JCP delivering standards: Entity Beans are a standard if they delivered the assumed benefits there would be scant interest in JDO. I don't know how to improve on the JCP but it's safe to say a successful implementation is a better basis for a standard than trying to create one by fiat. We have put too much faith in standards and are trying to create them before they're ready.

    Specific to this thread is the assumption that Transparent Persistence is Good. I take this to mean OO programmers don't need to know database programming. Side B will have OO programmers who learned database programming because they had to.

    Sorry to rain on the kickoff report but this rant had to come out somewhere.
  36. More == Better![ Go to top ]

    Let's get something pretty clear about JCP standardization that people all too often forget.

    The primary reason why we want standardization is that we, the buyer, want to be able to swap implementations without being locked in to a single vendor. One of the most effective JCP standards out there is the JMS standard. This has created a thriving marketplace of vendors, many of them with their own innovative features.

    The world wants the same kind of solution for O/R mapping in the Java world. If you place "transparent persistence" as priority of standardization of O/R mapping, then might be asking for something that's in conflict. If you can get transparent persistence, the I would say that's a good thing, however if you can't I don't think that's a failure of the spec.

    I think this entire spec would be heading for big failure if its trying to develope something "nebulous". 80% of O/R mapping is already well understood (see crossing the chasm), why not just stick with that and standardize that. Heck with the other tricking 20% of the problem that'll result in endless debate.

    I do hope you all understand what I'm trying to say. Forget about trying to innovate, the world needs standardization, just make it open enough such that the vendors themselves can innovate. It you have the urge to innovate, then think of a way of developing the API such that it supports compatibility at the same time differentiation.

    Carlos
  37. More == Better![ Go to top ]

    For some strange reason, I get this feeling that people think "transparent persistence" is a worthwhile goal. My thoughts on this is that it's "leaky" abstractions at its worse.

    "Transparent persistence" also does not imply "implementation hiding". That is you can achieve vendor substitutablily without "transparent persistence". The problem with the JDO spec., and I hope you don't try to maintain backward compatability, is that its under this false belief that you can achieve "transparent persistence" without sacrificing performance.

    It's akin to saying to the CORBA thinking that you can ignore the network and just do object messaging. Well we all know that that's a prescription for disaster. Same goes with persistence, if you try to gloss over certain aspects that can't get glossed over then your in big trouble.
  38. Standardization versus innovation[ Go to top ]

    I do hope you all understand what I'm trying to say. Forget about trying to

    > innovate, the world needs standardization, just make it open enough such that
    > the vendors themselves can innovate. It you have the urge to innovate, then
    > think of a way of developing the API such that it supports compatibility at the
    > same time differentiation.

    That's how the Linux Standards Base was standardized. It looked at what distributions were currently doing and standardized the largest approximate commonality. No Linux distribution was LSB compliant, but they were all close enough that compliance became pretty straightforward, which is why the LSB is successful and supported by all major Linux distributions.

    C was also standardized this way. The C committee looked at all current implementations and standardized common practise. C was definitely successful and ANSI/ISO C compliance was/is common.

    C++, OTOH, chose to innovate rather than standardize. C++ went from a simple language that any C programmer could pick up in an afternoon (or two) to a monster that even it's creator admits to not knowing the full power of the language. Most compilers out there *still* don't fully support C++ (I believe GCC and Comeau are now compliant, but it only became so just last years or so). The C++ in most common use is pretty close to the original version (mostly single inheritance with minimal use of templates and exceptions and RTTI), so I don't consider C++'s standardization to be too successful even though C++ is.

    IMO, committees do a poor job of innovating without throwing in a gold plated kitchen sink so that everyone on the committee has his pet feature (e.g. Ada-83). They are good at standardization because if agreement can't be found, the point of contention is simply dropped from the standard or declared "implementation dependent".
  39. Did Ward from Cocobase show up with a team of legal strongmen to force the discussion to a close? You wouldn't want to screw with their patents.
  40. What we need is a standardized way to do O/R mapping for Java objects. Enterprises do this, they do it a lot, and hence it should be standardized.

    The bottom line of standardization is that it should give portability: I should be able to swop from Tool A to Tool B with minimal distruption.

    The BIG risk you run at the moment is that if you want to swop from one Java O/R tool to another tool, that other tool must be able to cope with mapping your relational schema to your OO schema. So if tool A can do 1:many mappings from tables to objects, and tool B cannot, then you cannot swop tools unless you rework your data model. For a true enterprise system, that's very bad. Data migration, even to supposedly isomorphic structures, is always a big, messy, buggy, unpleasant, high-risk exercise - business users get *very* nervous, reconciliation becomes a big expensive exercise to check it all worked, data warehousing and auditting get major flow on issues, DBAs and Java programmers approach violence (seriously: the fact that you need two different skill sets to do this usually means different people with different understandings, and that does increase your risk). It's a big mess.

    Currently the only sure way to avoid this risk is to always map Java objects 1:1 into database rows, and not use inheritance for objects that you persist. That is not acceptable for many java architects and data modellers (for good reasons).

    A spec that says things like "To be Java O/R Mapping compliant you must support 1 to many, many to 1 and many to many mappings from tables to objects, you must support all 3 standard ways to model inheritance in a database", etc, would solve this. That is: High level specification of what types of mappings must be supported is required.

    If that spec also has more in it about low-level details (eg gave a XML Schema for the O/R mapping), fine, that'd be a bonus. But if your app is well built then rewriting the XML mapping files and java middleware actually isn't the biggest issue (ease of maintenance is why we use Java, remember?).

    This is NOT just a JDO issue. A single O/R spec that defines what types of mappings you must support to be a Enterprise class Java O/R mapping tool could apply to JDO, CMP and even to tools that support neither JDO nor CMP. But for JDO (at least!) to include such a O/R spec would be a huge step forward for Java Enterprise persistence tools.


    Sean
    PS: does anyone have an e-mail address I could send this rant to, to get it seen by those involved in the JCP?
  41. Hi,
    I am not a JDO fan, but I am going to change my opinion if specification will drop PersistenceCapable or make it optional and I like "SQL query" proposal.
    I do not think it is very common to migrate from some implementation or datastore, but standard API is usefull for IDE and code generators.
  42. Hi,

       I don't know about you all, but I waste the most time just getting the connection string for various databases and JDBC drivers to give me a connection. I end up modifying too much of my code when I want to port to another JDBC driver or database. Why can't there be a more standard syntax that would allow one simple and standard way to connect and modify a connection for another database?

    Then, I waste more time worrying about whether and when to go through the

    stmt.close();
    stmt=null;
    rs.close();
    rs=null;
    dbcon.close();
    dbcon = null;

    routine to make sure that the connection didn't time out or I have too many connections, etc., etc....as I worry about performance of the garbage collector and the memory consumption of the various (possibly multiple and numerous) objects.

    Why should I have to worry about all this BS? Why can't the database connection worry about these issues for me and automatically do the "Right Thing" tm.

    Sorry about the rant, but I was hoping JDO would fix this too.

    -Tom Schaefer
  43. Tom,

    Have you considered Spring's JdbcTemplate and related convenience classes? They relieve the application developer from those resource handling details. An update can be as simple as follows, with proper resource handling:

      jdbcTemplate.update("UPDATE ...");

    For ResultSets, there are callback interfaces that can be implemented as anonymous classes:

      final List names = new ArrayList();
      jdbcTemplate.query("SELECT * FROM media_folder",
        new RowCallbackHandler() {
          public void processRow(ResultSet rs) throws SQLException {
    names.add(rs.getString("name"));
          }
        }
      );
     
    Together with transactions, be it via JTA or Spring's generic transaction management, this approach works very nicely.

    BTW, JdbcTemplate is easily reusable as library, you don't need to use a Spring application context or any other Spring functionality for it. We even got an own JAR file in the distribution for that kind of usage as data access library.

    Juergen
    Spring Framework developer
  44. Then, I waste more time worrying about whether and when to go through the

    >
    > stmt.close();
    > stmt=null;
    > rs.close();
    > rs=null;
    > dbcon.close();
    > dbcon = null;
    >
    > routine to make sure that the connection didn't time out or I have too many connections, etc., etc....as I worry about performance of the garbage collector and the memory consumption of the various (possibly multiple and numerous) objects.
    >
    > Why should I have to worry about all this BS? Why can't the database connection worry about these issues for me and automatically do the "Right Thing" tm.
    >
    > Sorry about the rant, but I was hoping JDO would fix this too.
    >
    > -Tom Schaefer

    As I understand it, JDO is not going to solve resource management problem, you will need some kind of "high level API", AOP or "finally close" for JDO too.
    There are a lot of "good" ways to manage resources and I do not think this stuff needs standard at this time.
  45. what's the problem???[ Go to top ]

    I don't really know what's going on peoples mind: if specs were a bad thing, this JCP stuff would have died long ago. It may be not perfect, sometimes some specs really add to nothing. But sometimes some specs really shine. On the other hand, specs are not the holy grail. M$ itself lives on without depending on specs, even going against some.

    So having a spec in itself can´t be deemed a good or bad thing. The quality of the spec it what matters. Create a good (and timely) spec, and it will shine by itself. Create a bad spec, and it will fade away.

    Now people here are complaining about what JDO should do, or to drop it and use Hibernate, or that JDO is the holy grail. It doesn't matter. What matters is the quality of the spec. JDO 1.0 didn't shine so much. Now some talented people are having a second chance of fixing things, and trying to do things the right way now. Let they do it, and just wait for the final spec. If it is good, it will live up. Else it will die. Simple.

    Still, having even a bad spec is better than nothing. Creates competition, avoid lock-in, and helps the industry to focus at the same time.
  46. JDO/R[ Go to top ]

    When can we expect to see at least a draft of the 2.0 spec? JDO/R (JDO 2.0), if it does happen within a reasonable amount of time, will be invaluable to a company like ours, e.g., where our CTO is concerned about vendor longevity/lock-in - why should we pick either one, Hibernate (whose LGPL license is something to be concerned about when (re)deploying it as part of a commercial software package), or Cocobase (which costs $6k), whom we don't know if they'll be around a year or two from now when you have other much cheaper(or even free) alternatives which are nearly just as effective? If we had a standard that properly addressed O/R mapping the way that either one of the packages I mentioned does, in addition to catering to the OODBMS vendors - well, you can't top that off. Even a less than 100% perfect solution, as Mr. Perez mentioned, would be acceptable if it can cover RDBMS and do O/R mapping correctly.
  47. lgpl again....[ Go to top ]

    Hibernate (whose LGPL license is something to be concerned about when (re)deploying it as part of a commercial software package) <

    The LGPL is triggered when you _modify_ Hibernate. As we state on our website, you are allowed to redistribute an (unmodified) Hibernate w/o any special requirements .
  48. "A Bad Spec is Better Than Nothing."

    I beg to disagree, the EJB spec is a bad spec and it's leading many to believe that Java development is overly complex.

    The vendors, have made their money at the expense of Java community as a whole.

    If we stuck with fundamentally sound standards like RMI and its improvement JINI, then we wouldn't be in such an ugly mess that we are all currently in.
  49. "A Bad Spec is Better Than Nothing."

    >
    > I beg to disagree, the EJB spec is a bad spec and it's leading many to believe that Java development is overly complex.
    >
    > The vendors, have made their money at the expense of Java community as a whole.
    >
    > If we stuck with fundamentally sound standards like RMI and its improvement JINI, then we wouldn't be in such an ugly mess that we are all currently in.

    OTOH, if there wasn't any spec for EJB, each vendor would have created its specific technology for server-side beans, leading to a much greater vendor lock-in and market fragmentation. Just look what we have now for O/R in java: JDO people fighting with OS people, fighting with stabilished O/R companies... All because JDO came too late, and now has a steep climb ahead. If there were a good JDO spec in the first place, there would be less fighting going on now. Resuming, in my point of view:

    1) a good spec at the right time: ideal situation, everyone playing in a level field. Either you're in and win, or you're out and lose.

    2) a good spec at the wrong time (too late): lots of fighting with already stabilished products, disputes for who will be the de facto spec, etc.

    3) a bad spec at the right time: frustration, partial market fragmentation, partial vendor lock-in, vendors trying to impose their own solutions for specs holes.

    4) a bad spec at the wrong time: some try to implement, but after some time it fades out. Usually degenerating to (5)

    5) no spec at all: vendor lock-in, proprietary, one or few vendors usually dominating the market.

    My 0.00002c

    "all my opinions are mine, unless otherwise instead, and vice-versa"
  50. I have heard very little criticism of what we specified in JDO 1.0 and JDO 1.0.1, except for the common criticism that we did not specify Object/Relational Mapping.

    JDO 2.0 improves on JDO 1.0 in many areas. On the whole this is being achieved by the addition of new content, rather than the fixing of broken content. We never believed JDO 1.0 to be broken, which is why we didn't formally commence the next major JSR until now. (JDO 1.0.1 took place under JSR12 and mainly served to clarify specification wording for the benefit of implementors.)

    JDO 1.0 was and is a good spec. It delivers very powerful functionality to users whilst ensuring implementability and eliminating ambiguity for the implementors.

    JDO 2.0 will be a superlative spec. It will deliver far greater functionality (not merely limited to addressing O/R standardization) and will retain the same degree of clarity for implementors.

    Kind regards, Robin.
  51. Hmmm. I had been encouraged by the attitude of most of the spec members up until this post. Now I'm wondering if JDO 2.0 will be just another ego-driven spec.

    "JDO 2.0 will be a superlative spec."

    We've got enough empty boosterism from every other competing technology. It's discouraging to see it from the JDO 2.0 team.
  52. Scott,

    I'm sorry if my language did not appear appropriate. Suffice it to say that I am excited about the proposed content, and by the extremely collaborative nature of the kick-off meeting. These two combined bode well for the future.

    The minutes of last week's kick-off meeting will be published shortly and should make interesting reading. Ultimately, however, you should judge JDO 2.0 on the results which we deliver and the timeliness with which we deliver them.

    I'd also like to clarify that I do not presently speak on behalf of the spec team. My opinions are my own, although I hope that my enthusiasm about JDO 2.0 is shared by others in the community.

    Kind regards, Robin.
  53. OTOH, if there wasn't any spec for EJB, each vendor would have created its specific technology for server-side beans, leading to a much greater vendor lock-in and market fragmentation. Just look what we have now for O/R in java: JDO people fighting with OS people, fighting with stabilished O/R companies... All because JDO came too late, and now has a steep climb ahead. If there were a good JDO spec in the first place, there would be less fighting going on now.


    The reason JDO 'came too late' is that all J2EE effort (Sun and all those people in positions of influence who pushed it) was directed at EJB. This is my biggest gripe with EJB, not that it is an overly complicated and flawed spec (which it is) but that all that time and effort was put into something that is actually needed for what 1 in 100 J2EE projects (...or there abouts !), when no effort was being directed toward things like O/R mapping and producing a spec relating to that. How much time, ground, and reputation has J2EE lost to its competitors in the mean time, because of this ? Why in August 2003 is choosing how to persist your data in a small/medium sized J2EE app very far from a straight-forward decision. Because of the calamity of EJB and those people that have been forcefully selling it to us for the past 4 years.

    Good luck with with JDO 2.0.
  54. Castor[ Go to top ]

    Is Castor JDO anywhere on the discussion.
  55. Castor JDO != Sun JDO[ Go to top ]

    This has been said many times in many different places on the 'net: Castor JDO is not compliant, or was it ever, with Sun's JSR 12, Java Data Objects, aka JDO. So I doubt that you'll hear much about Castor JDO other than that it's not Sun JDO compliant.

    --matthew
  56. Added Points[ Go to top ]

    I am late for replying to this topic, but this discussion seeming very interesting and useful for JDO 2.0. As it is seeming a superset of all the features from existing JDO, attach-detach implementation related issue from Kodo JDO, and advance deletion and query features from Hibernate. If all these features can be included in JDO2.0, that would be great for all OR implementor. I am not going to add details about topics, just have points which can be considered like:

    1). Read only properties should be supported. This is useful when you are working on client tier and in a disconnected mode. Use case is:

    You are showing some data objects in a combo and selected combo is binded with any property of underlying main data object. And you are also providing feature to update that combo property as a separate serialization unit, ie in a separate UI. Then on reconnecting data object with JDO system, you will get concurrent updation exception. This can be avoided if JDO can support read only properties, as in that case, it will not go for concurrent updation check for that property. Otherwise implementor needs to do some workaround, either at designing level or at coding level.

    It is supported by Hibernate.

    2). Collection ordering can be supported based on given criteria in mapping file (like for one - many relationship), this is also supported in Hibernate.