Discussions

News: Opinion: For JDO, the Time Is Now

  1. Opinion: For JDO, the Time Is Now (33 messages)

    Bruce Tate, author of the Bitter series, has written an opinion piece on transparent persistence. He discusses the evolution of java persistence, the trend toward a "Simpler Java", and finishes up with thoughts on what the JDO group need to come up with.

    Bruce's thoughts on what JDO needs to do
    1. Finalize the 2.0 specification quickly. If it takes the JDO expert group as long to get 2.0 out as it did 1.0, it's dead. Right now, the 2.0 spec is scheduled to be delivered this year. It mustn't slip.
    2. Address OR mapping. The primary obstacles to OR mapping in a JDO specification are no longer in force. Specifically, no proprietary OR mapping solution is dominant, and relational database vendors don't face any real competition. JDO 2.0 will include OR mapping support.
    3. Embrace SQL. JDO needs a broadly accepted standard that addresses the needs of its community. JDOQL can still be supported for non-relational frameworks, but it won't ever be a mainstream language. Hibernate shows that an SQL dialect can succeed in a persistence framework. Right now, SQL is a possibility as a pluggable query language. SQL (or a close derivative) should be included in the overall standard.
    4. Separate implementation details from the specification. Don't give customers another reason to reject JDO. Bytecode enhancement doesn't need to be a problem. Let customers choose JDO for its benefits and then choose bytecode enhancement where they feel it makes the most sense. The JDO 2.0 spec will no longer mandate bytecode enhancement. The JDO expert group will gain the biggest benefit from allowing frameworks like Hibernate and TopLink to participate in the standard.
    5. Don't push binary compatibility. For most of JDO's potential customer base, it's not an issue. Few other J2EE standards enforce binary compatibility. Binary compatibility gets in the way of other important aspects of the spec. It looks like JDO 2.0 will make binary compatibility an optional feature, which existing vendors will continue to support.
    6. Get big-name support. From the very beginning, lack of a big-ticket vendor has been a critical limitation for JDO. Oracle or IBM would be ideal. SAP also has a JDO implementation, and it is increasing its involvement with the JCP. Right now, TopLink and Hibernate appear to be strongly considering support of the JDO 2.0 standard. Either or both would go a long way toward relieving customer concerns that JDO is a small-time player.
    All of these points are very much on the mind of the JDO expert group, so I expect Bruce will be happy with the outcome.

    Read For JDO, the Time Is Now

    Read the notes from the JDO 2.0 kick off meeting

    Threaded Messages (33)

  2. Hi All

    I think people are a lot less opposed to bytecode enhancement these days with all the aspect stuff going on. Anyway binary compatibility (i.e. bytecode enhancement) will definitely be optional in JDO 2.0.

    Cheers
    David
    www.jdogenie.com - High performance JDO O/R mapping
  3. How is a class without dependencies not binary compatible? Why all this talk about binary compatibility?
  4. JDO 1.0 required that all implementations use bytecode enhancement and that they all do it in exactly the same way. JDO 2.0 is going to make bytecode enhancement optional so implementations that generate proxies and so on can be JDO compliant. JDO implementations that use bytecode enhancement must still stick to the standard (i.e. be binary compatible) so that classes enhanced by one vendor can be used with another vendors product.
  5. There is no requirement for bytecode enhancement in JDO 1.0, it's a requirement for a particular interface. Has this requirement been removed or are we talking about workarounds for previously introduced mistakes? It would have been nice if Bruce did less handwaving and more technical talk.
  6. Hi Christian

    "There is no requirement for bytecode enhancement in JDO 1.0, it's a requirement for a particular interface. Has this requirement been removed ... ?"

    Yes I believe PersistenceCapable is going to be dropped. The spec will likely read "persistence-capable" instead. Binary compatible implementations will still enhance classes to be PersistenceCapable. Other implementations will use proxies or whatever to do dirty tracking, lazy loading and so on.

    It will be interesting to see which approach gives the best performance and the most transparency. An apples to apples comparison will be possible with implementations with different strategies implementing the same spec.

    Cheers
    David
    www.jdogenie.com - JDO Genie - High Performance JDO O/R mapping
  7. Until JDO 2.0, the time is not yet[ Go to top ]

    Saw a decent presentation on JDO last night (the powerpoint font was far too small for a room full of [blind] developers). It seemed that nearly every time someone asked about a [seemingly] core piece of functionality, it wasn't in 1.0, but was going to be in 2.0.

    It convinced me of 2 things:
    1) JDO 2.0 will be fairly effective and usable for most enterprise needs.
    2) I wouldn't touch JDO 1.0 with a 10 foot pole. Though most vendors probably implement most of the needed functionality not in the spec, untangling their best-guess proprietary implementation when it comes time to upgrade to JDO 2.0 will probably e a dicey endeavor.
  8. Until JDO 2.0, the time is not yet[ Go to top ]

    Hi Rob

    Right now porting between JDO 1.0 vendors is not difficult. Most vendor extensions can be isolated into static utility methods. Vendors also have very similar mapping meta data. Many JDO 2.0 features are based on things vendors already have so changing to JDO 2.0 will not be difficult.

    With the standardization of the O/R mapping side of JDO (JDOR) all vendors will support their current mapping meta data and the new JDOR meta data. JDO Genie will certainly have an easy way to convert to JDOR meta data. So you can use JDO Genie now with a lot of success and single-click convert to portable JDO 2.0 JDOR mapping when that is released.

    Cheers
    David
    www.jdogenie.com - JDO Genie - High performance JDO O/R mapping
  9. When Will the JSR be submitted?[ Go to top ]

    We've been hearing for quite a while now about JDO 2.0, and yet no JSR has been submitted so far. What are you guys waiting for? For the next revision of the JCP process? I'm sure you have had enough time to go over most of the major issues to be covered. Besides, with the brand spanking new JCP process you'll be given plenty of time to get a lot of feedback from the community at a large to make changes before the JSR is up for a ballot. So there's no pressure there anymore. What's the holdup?
  10. When will JDO 2.0 JSR be submitted[ Go to top ]

    We've been hearing for quite a while now about JDO 2.0, and yet no JSR has been submitted so far. What are you guys waiting for? For the next revision of the JCP process? I'm sure you have had enough time to go over most of the major issues to be covered. Besides, with the brand spanking new JCP process you'll be given plenty of time to get a lot of feedback from the community at a large to make changes before the JSR is up for a ballot. So there's no pressure there anymore. What's the holdup?
    You are right that the working group preparing for the JSR has gone over all of the major issues. And the new JSR process allows community and public review far earlier than before (which is a good thing).

    The holdup in submitting the JSR is on my (Sun's) end. I expect the JSR to be submitted by the end of this month, and to have a public version of the draft specification available well before Java One 2004.

    Craig
  11. Opinion: For JDO, the Time Is Now[ Go to top ]

    Jini, JDO, this is the day of the Java technologies of the future. Yes it's me again, I just wanted to put in a good word for JDO. We've chosen JDO as a persistance solution and we're looking to integrate it with Jini too. There's no reason why we/one/someone shouldn't be able to get Jini persistance working through JDO, i.e. the JavaSpace uses JDO to persist it's Entrys.

    This is programming at its simplest, JDO and Jini, a nice contrast to EJBs. Ooops did I really say that???

    Don't you just love Java!

    -John-
  12. Ok so entity javabeans are crap, JDO ( in it's present form ) requires yet
    another developer task between code, deploy, test cycles.

    Why don't we just take Hibernate and orient the entire standard around it.

    I think it's a good idea for the following reasons.

    1) It works
    2) It has a low bullshit quotient
    3) It was developed by someone that had a clue as opposed to some ivory tower
    boffin that works for a company that benifits from slower code needing more
    system resources and thus increasing their flagging server sales.

    Entity beans with their crap performance ( and yes it is crap because we
    benchmarked it at the time ) and JDO with it's stupid bytecode enhancement
    are not providing people with what *they want* . Instead they pander to those
    twats who believe everything that they read in that glossy sales literature.

    Who cares what sun think ? Open source is the real standards body and people
    are voting with their feet.




    --B
  13. There are a lot of ways to map object to table and I do not think some of ways is proved to be the best. Select the way you think is good for you and use it without any standards.
    You say EJB entities is a crap, yes it is true, the same will be about JDO later. Somebody can invent a new way to access database and we will need a new standard to save/load data and to make it object oriented.
  14. SDO[ Go to top ]

    If you feel OR mapping and Domain models are the correct way to implement applications, then JDO/Hibernate/Entity Beans are ok. But I spec I think that will be more beneficial to J2EE applications is SDO.
  15. cool[ Go to top ]

    There's this exciting technology called JDBC for accessing relational databases. It's very easy to use and speeds up development time. Try it out - JDBC.
  16. cool[ Go to top ]

    There's this exciting technology called JDBC for accessing relational databases. It's very easy to use and speeds up development time. Try it out - JDBC.
    -1 Troll
  17. cool[ Go to top ]

    There's this exciting technology called JDBC for accessing relational databases. It's very easy to use and speeds up development time. Try it out - JDBC.
    -1 Troll
    I agree JDBC is a very good way to access database. It is not the best way,
    I use plain jdbc for most of use cases, but I found it is better to use it indirectly, it is too low level API for application developers. JDO is low level API too and it needs some wrapper API or code generator. JDO avandages are not visible if you use wrapper or code generation, wrapper for JDO looks like wrapper for JDBC, no major difference, but more XML garbage.
  18. Scott McCrory[ Go to top ]

    -1 Technology Lemming
  19. Object Relational Bridge ...[ Go to top ]

    It surprises me that so few people mention OJB (Object Relational Bridge) any more. In my experience, it is a great O/R mapping framework and it has support for JDO using the JDO reference implementation. I have to admit, I've only ever used the Persistence Broker API, but it does everything I've ever wanted to do.
  20. Opinion: For JDO, the Time Is Now[ Go to top ]

    JDO also needs a complete TCK, address "complex" O/R mappings issues and not only simple ones and a much more detailed specification.


    By the way, I would like to include that JPOX, www.jpox.org, is the first open source implementation full compliant with the JDO spec.
  21. Opinion: For JDO, the Time Is Now[ Go to top ]

    [ The views expressed here are my own; to be explicit I am not writing on behalf of the JDO Expert Group]

    I agree with Bruce. The time is now, and I don't intend to see that opporunity missed.

    When JSR12, the original JDO JSR, was approved, the JDO Expert Group officially became the JDO Maintenance Group and delivered the point release JDO 1.0.1. We then watched the community's response to JDO and gathered experiences (our own and those of customers) of using JDO in the field. In June last year we convened a meeting to set the scope of JDO 2.0, which was published on TSS.

    Since then the experts have been working on JDO 2.0, debating the possible semantics of each JDO 2.0 feature and achieving consensus across those who have embraced the PersistenceCapable architecture, and those new members wishing to implement JDO 2.0's complete feature set with an alternative underlying architecture, perhaps more reflection-based.

    Coincidentally, whilst this work has been on-going, Craig Russell has been taking the necessary steps to secure a commitment for the implementation of the JDO 2.0 RI (every JSR needs one) and the establishment of the JSR process. This is not yet concluded, which means the work we're doing on JDO 2.0 can be freely discussed in public. As soon as the JSR is started we'll have to stop being so free with content until we release the first community draft.

    JDO 2.0's feature set can be roughly broken down into four major areas: JDOQL, Detachment, JDOR and Miscelaneous. Work on JDOQL is essentially complete, as is the Miscellaneous work (bar the Sequence abstraction I want!). In the last three weeks we have put together a solid set of semntics for Detachment, which improves significantly over the initial Detachment concept we had after the Kick-Off meeting. There are still some issues that need to be resolved so that the semantics are agreeable to the PersistenceCapable and non-PersistenceCapable members, but I don't think that will take long. A set of JDOR mapping examples is under debate in the group, and although this will certainly give rise to some changes to the underlying XML Schema that has been proposed, it is again likely that this work can be concluded reasonably quickly.

    Craig hopes that we'll convene the JSR in a couple of weeks time. I hope that we will be able to publish the first JDO 2.0 Community Draft about 10 days after that!

    Kind regards, Robin.
  22. Opinion: For JDO, the Time Is Now[ Go to top ]

    Here are my comments on Bruce's 5 points.

    1. Finalize the 2.0 specification quickly

    We intend JDO 2.0 to have had wide community circulation before JavaOne, and for JDO vendors exhibiting at JavaOne to have implementations that are "effectively" compliant with the new spec. Of course the TCK won't exist yet, so I don't think compliance will be verifiable at that stage.

    2. Address OR mapping.

    We have a comprehensive set of mapping scenarios which we are addressing, whilst leaving a means for vendors to go beyond the standard and support more esoteric mappings as required.

    3. Embrace SQL

    We won't do this. Not in so many words. But the Projection, Aggregation, Grouping and Having concepts going into JDOQL give you a very flexible object-level query language which can provide field-level results if required. We're also providing a standard means to get the underlying connection to your datastore (enlisted in the current transaction), but what you do with that connection is up to you; portability at that level only exists in-so-far-as the SQL standard assures it, so essentially you're on your own.

    4. Separate implementation details from the specification.

    Yes. The JDO 1.0 spec REQUIRED vendors to use the PersistenceCapable interface. Bytecode Enhancement was never required, but is more transparent than asking developers to implement PersistenceCapable manually and so found widespread support by Vendors and Users. An additional Ant target, post-compile enhancement, is not an issue. However the new spec will not mandate use of the PersistenceCapable interface. The spec will identify the required semantics of object persistence, leaving implementation choices open to the vendors. We expect that many vendors will retain their PersistenceCapable architectures, which have proven to be very effective and efficient, and we invite those vendors to support the binary compatibility option so that classes enhanced once can be used against different JDO implementations without any need for re-enhancement.

    5. Don't push Binary Compatibility

    As per 4.

    6. Get big-name support.

    There are initiatives underway to improve JDO's positioning by licensing JDO technology to big players and encouraging the J2EE people to include JDO in a future release of J2EE. However by far the biggest leverage is from the customer base. If the TSS membership which use BEA's platform went to BEA, and the WebSphere users went to IBM, and asked in concert for JDO support, then the big players would get on board very quickly. I'd love to see that happen.

    Kind regards, Robin.
  23. Will JDO (and it's OR mapping) support:

    a. No object ID's in the database - only primary keys including composite (multi column) ones.

    b. No version column or any other special constructs required for true optimistic locking.
    Essentially we require optimistic locking something like this:
    1. Select some data from the database.
    2. Clone the data keeping the original and a reference to it in the clone.
    3. Send the cloned data off to the client for any updates (in a GUI normally).
    4. The client sends the updated clone back to the server with it's reference (some kind of key) to the original data.
    5. If the data is from one row in one table a simple update statement is created with a where clause:
    primary key = value(s) from original data
    other fields = values form original data
    with options for "other fields" to normally be all fields that where read from the database (where in the original data) but also a specified subset of those fields or specifically the fields that where changed (but in this last case an option to leave some of these fields out as well).
    If the data was from several tables more elaborate systems must be supported, but also based on the same idea. An example might be an order with an order header and lines. One could always delete all lines from the database and insert the lines returned from the klient and leave "locking" check to the header only. For many applications that would be perfectly acceptable. Individual updetes, deletes and inserts of lines must however also be supported, but then with an additional problem of checking for new insertions since the original data where selected. A combination of the two is also possible.
    More complex data might require more complex updates and it must of course be possible to hand code specialized support.

    6. If the update in point 5 was successfull all is ok.
    If the update was not successfull (no row updated because someone else had changed some data) we simply roll back the transaction and return this fact to the user.

    Of course the details may vary widely here, but the essence is the final update with a where clause with all or some spesific subset of the fields of the table.

    Nils Myklebust
  24. Hi
    Will JDO (and it's OR mapping) support:a. No object ID's in the database - only primary keys including composite (multi column) ones.
    Yes. Nearly all vendors support application identity (the JDO term for this feature of JDO 1.0) already and composite primary keys. The JDOR mapping spec will standardize mapping for this but even now primary key mapping is very simple and similar between vendors.
    b. No version column or any other special constructs required for true optimistic locking ... a simple update statement is created with a where clause:primary key = value(s) from original dataother fields = values ...
    I am not sure if optimistic locking modes have come up on the expert group yet. I will mail something on the topic and find out. JDO Genie supports "changed" locking where we include the old values of exact non-blob types in the where clause - what you want. This is not as efficient as a version number but useful for legacy schemas.

    The JDO 2.0 attach/detach API will handle the bit about cloning (detaching) the graph and sending it off to the client and bringing changed/new instances back into a PM (attaching). Detatched instances will carry version information that can be easily checked on reattachment. This is normally going to be a simple version number but nothing stops the implementation from storing the original values of the fields in it.

    If the original values of the fields are not included in the detached graph then the server has to keep a copy of every graph detached and sent to a client. These copies might need to be kept for an indefinite length of time so this is not a scalable solution.

    Cheers
    David
    www.jdogenie.com - JDO Genie - High Performance JDO O/R mapping
  25. Hi Nils

    I have just checked and JDO 2.0 will standardize optimistic locking strategies and mapping. There is a strategy called "state-comparison" that will do what you want.

    Cheers
    David
  26. Thanks for jumping in there, David.

    Whilst we're on the topic, what else does the TSS community require to be covered by the JDOR spec?

    Erik commented:

    > That's really great. Will identifying relationships be supported in JDO 2?

    Thanks Eric. As far as "identifying relationships" are concerned the phrase can have different meanings depending on your perspective. Usually it is a propagation of the Parent's primary key fields into the Child's primary key. This means that (a) the Child cannot exist before the Parent, and (b) the Child must be deleted when the Parent is deleted.

    The propagation of primary key information from one table to another is not really a JDO issue as much as a Relational Schema issue. If you set up your tables that way you can already map them with JDO 1.0 using application identity, although many designers are moving away from such Schema constructs towards usage of object ids instead. What JDO 2.0 will add to this is the ability to configure cascade-delete semantics over a relationship.

    Is this what you were looking for?
  27. As far as "identifying relationships" are concerned the phrase can have different meanings depending on your perspective. Usually it is a propagation of the Parent's primary key fields into the Child's primary key. This means that (a) the Child cannot exist before the Parent, and (b) the Child must be deleted when the Parent is deleted.The propagation of primary key information from one table to another is not really a JDO issue as much as a Relational Schema issue. If you set up your tables that way you can already map them with JDO 1.0 using application identity, although many designers are moving away from such Schema constructs towards usage of object ids instead. What JDO 2.0 will add to this is the ability to configure cascade-delete semantics over a relationship.Is this what you were looking for?
    Yes it's the parent-child dependancy I'm looking. Take this example:

    class Parent
    {
      String fieldParentA; //pk
      String fieldParentB; //pk
      String fieldParentC;
    }

    class Child
    {
      Parent theParent; // pk
      String fieldChildA; // pk
      String fieldChildB;
    }

    How is that supported by JDO ?

    A pm.getObjectById(theChildStringID) would not work as the Child$Id class does not have the pm to reconstruct the id.

    Thanks
  28. Hi Erik
    A pm.getObjectById(theChildStringID) would not work as the Child$Id class does not have the pm to reconstruct the id.
    This can be done easily in JDO 1.0.1 with implementations that support mapping columns to multiple fields (like JDO Genie). The trick is to use a normal primary-key allowed type for the PK and map the reference field to the same column(s):

    class Parent
    {
      String fieldParentA; //pk
      String fieldParentB; //pk
      String fieldParentC;
    }

    class Child
    {
      String fieldParentA; //pk mapped field_parent_a
      String fieldParentB; //pk mapped field_parent_b
      String fieldChildA; // pk
      Parent theParent; // mapped to field_parent_a, field_parent_b
      String fieldChildB;
    }

    // objectid-class for Child
    class ChildPK implements Serializable {
      String fieldParentA;
      String fieldParentB;
      String fieldChildA;
      ...
    }

    The implementation needs to be quite smart ubout inserts, updates and field == null in JDOQL when using this kind of mapping.

    Cheers
    David
    www.jdogenie.com - High Performance JDO O/R Mapping
  29. This can be done easily in JDO 1.0.1 with implementations that support mapping columns to multiple fields (like JDO Genie).
    That's nice to that JDOGenie supports it David, but I see it as a workaround to a JDO limitation. Only mature implementations support such a feature which is not standard.

    But I think my first code is much clearer than the required code for the workaround.

    I think, a change in the object id class spec should be done to support this kind of relationship.
  30. Hi Erik
    I think, a change in the object id class spec should be done to support this kind of relationship.
    If someone could figure out a way to permit references to persistent classes as primary keys cleanly I am sure it would be considered by the expert group. The identity fields of an instance need to always be accessable and the objectid-class must be Serializable. Both of these are a big problem for JDO managed instances in the PK. I am sure there are probably other problems.

    Cheers
    David
    www.jdogenie.com - High Performance JDO O/R Mapping
  31. Support for parent-child dependancy[ Go to top ]

    Hi Eric / David

    What appears to be required is a scheme in which a user-provided ObjectID Class for instances with Application Identity can contain references to other ObjectID classes. So ChildPK could have a reference to an instance of ParentPK. The JDO spec would need to allow individual fields of ParentPK to be mapped to the Child table as part of the ChildPK identity mapping.

    This is not proposed for JDO 2.0. If the community requires it we can add it to a JDO 2.1 proposed features list. In the mean-time such schemes can usually be achived through exploiting a feature of one of the "mature" O/R implementations, but not in a standard/portable way.

    By the way, those of you who are interested in JDO but don't want to pay for one of the four JDO books can download the PDF of Java Data Objects by Roos through my website, www.OgilviePartners.com. Of course I hope you'll eventually buy the book anyway. It's slim enough to slip into a brief case and entertaining enough to make good bed-time reading.... ;-)
  32. I see it as a frequent requirement, and this can be done, if I'm not wrong, by changing the implementation for the methods jdoCopyKeyFieldsToObjectId and jdoCopyKeyFieldsFromObjectId and following the below example for classes

    class Parent
    {
      String fieldParentA; //pk
      String fieldParentB; //pk
      String fieldParentC;
    }

    class ParentId
    {
      String fieldParentA; //pk
      String fieldParentB; //pk
    }

    class Child
    {
      Parent theParent; // pk
      String fieldChildA; // pk
      String fieldChildB;
    }

    class ChildId
    {
      String fieldParentA; //pk
      String fieldParentB; //pk
      String fieldChildA; // pk
    }

    <jdo>
    <class name="ChildId"..>
      <field name="theParent" primary-key="true" identifying="true">
         <identifying field-name="fieldParentA"/>
         <identifying field-name="fieldParentB"/>
      </field>
    ...
  33. 6. Get big-name support. There are initiatives underway to improve JDO's positioning by licensing JDO technology to big players and encouraging the J2EE people to include JDO in a future release of J2EE. However by far the biggest leverage is from the customer base. If the TSS membership which use BEA's platform went to BEA, and the WebSphere users went to IBM, and asked in concert for JDO support, then the big players would get on board very quickly. I'd love to see that happen.
    A quick question: how you see Hibernate's path comparing with JDO's? Is there any possibility to have Hibernate standardized?

    Cheers,
    Aleksandar
  34. Opinion: For JDO, the Time Is Now[ Go to top ]

    I hope that we will be able to publish the first JDO 2.0 Community Draft about 10 days after that!Kind regards, Robin.
    That's really great. Will identifying relationships be supported in JDO 2?