Women in Technology

Hear us Roar

Subject:   On becoming persistence-capable
Date:   2002-12-11 04:55:12
From:   robin@ogilviepartners.com
This may be the first of several messages I write here, so let me begin by saying I'm Robin Roos, author of the book "Java Data Objects" and a member of the JSR12 (JDO) Expert Group. My services portfolio includes vendor-neutral JDO training and consultancy, alongside more "traditional" J2EE equivalents.

Now that I've declared my interests up-front, let's talk about JDO.

David Jordan's commentary is certainly what might be called "spirited". That aside, it serves an important purpose. There is a new standard - JDO (JSR12) - which a lot of people have associated with the product "CastorJDO". The term "JDO" certainly appears regularly on the index page at http://castor.exolab.org/ so this confusion is understandable.

It is unhelpful for JDO (JSR12) that this branding confusion exists, although resolution is only likely if the Exolab Group decides of its own vollition to rebrand their existing product....

Suffice it to say that CastorJDO and JDO (JSR12) differ in such substantive ways as to make direct comparison largely irrelevant. This can be expanded upon in separate message threads if required.


On the bytecode enhancement front, users of JDO (JSR12) are not under any obligation in this regard. If you wish, you may code your class to implement the javax.jdo.spi.PersistenceCapable interface. You must then provide the concrete method implementations required for support of the interface. The fact that these are entirely predictable and inherently boring to implement makes bytecode enhancement my preferred approach. But you do have the choice.

On a final note, and at the risk of confusing the thread, we have Java Generics coming down the track (JSR14, in which I am not directly involved). This will introduce new language elements, so that a Vector known to contain only instances-of Customer, could be declared as:

Vector<Customer> customers;

These changes introduce specific class type-safety for methods of the generically-defined Vector class. Support for "generics" will introduce new language elements, potentially alter the bytecode structure of compiled classes, and represent a major step in the evolution of Java technology.

Do I have a point? Yes, I do, and here it is:

Should we be targeting this same timeframe - in which the language will change anyway to support "generics" - for the introduction of a "persistent" modifier for the "class" statement? E.g.

public persistent class Customer {

which might create a class which implicitly implements the PersistenceCapable interface, providing all of the requisite method implementations. This would remove the requirement for bytecode enhancement.

What do you, the readers of this thread, think of that as an idea? It's not something that the JSR12 group is actively working towards, but it would certainly remove the bytecode enhancement debate and integrate object persistence into the heart of the java platform.

At this stage I am not suggesting that the introduction of a "persistent" keyword is likely, or that it is a "good idea". However I think it is an interesting concept, and look forward to your comments.

Kind regards, Robin.
Robin M. Roos

Full Threads Newest First

Showing messages 1 through 3 of 3.

  • On becoming persistence-capable
    2002-12-11 22:07:13  srdrucker [View]

    I think the best would be doing what you stated in a previous post:

    [A "technically pure" JDO implementation would rely on JVM-level hooks into the transient object lifecycle which could be used to trigger corresponding events in a persistent object cache.]

    A JVM-Level hook would support three Major Goals:
    -Provide ability to populate hollow data.
    -Easily sense when an object becomes dirty.
    -Support both field-level and public-interface level persistence (Sun JDO vs. java.bean.XMLEncoder style).

    The hook could be modeled as follows:

    -Add two new methods to Object:
    addObjectListener(ObjectListener listener, String[] fields, Method[] methods) and removeObjectListener(ObjectListener listener).
    -ObjectListener would have three methods, fieldRead(FieldEvent e), fieldWrite(FieldEvent e), invocation(InvocationEvent e)
    -fieldRead(FieldEvent e) would provide opportunity to populate hollow data.
    -fieldWrite(FieldEvent e) would provide sensing of dirty objects.
    -invocation(InvocationEvent e) would provide both FieldRead and FieldWrite functionality for public interface persistence through monitoring of methods (usually getters and setters).

    The fieldRead method would only be called once on the first access of each field registered (to provide the appropriate value if hollow). fieldWrite would be used to sense dirty state. invocation() would only be called the first time the method is invoked.

    Finally, in my view, Object Persistence is the last hurdle to Java in the business world. I worry that Sun is not going to modify the VM for object persistence. There should be a jcp on this.

    My 2 cents.
    • On becoming persistence-capable
      2002-12-13 03:06:20  robin@ogilviepartners.com [View]

      You deliver good value for just 2c!

      I know that most members of the JDO (JSR12) Expert Group are reading this forum and we should have further input on this. However any alteration involving the JVM spec should be considered a long road to go down.

      In the mean-time the PersistenceCapable interface is facilitating persistence hooks that execute very quickly for enhanced versions of classes, whilst having no impact on un-enhanced classes.

      The domain object models and applications you persist with JDO today should be portable to future strategies of JDO implementation (VM hooks, "persistent" class modifier, etc.) when and if these arise.

      And remember that enhanced classes are not enhanced in a vendor-specific manner, but the same enhanced bytecode can be used with alternative JDO implementations. On the whole I believe that JDO provides a sound and future-proof architecture for transparent persistence.

      But that's my opinion. What do others think?

      Kind regards, Robin.
      • On becoming persistence-capable
        2002-12-13 07:56:59  srdrucker [View]

        The other route that would be acceptable to the anti-byte-code manipulation (I can't seem to stomach the word "enhancement") and anti-PersistenceCapable crowd would be to have an "Explicit Mode". This would be based on the following methods:

        PersistenceManager.retrieve(Object object)
        -This method already exists and could be used to explicitly retrieve all hollow instances in an object.

        PersistenceManager.retrieve(Object object, String field)
        -This method would retrieve a specific hollow field (or property).

        PersistenceManager.makeDirty(Object object)
        -Add method based on StateManager.makeDirty(Object object, String string) to make an object dirty.

        In "Explicit Mode", the application has the resposibility to retrieve hollow instances and make objects dirty. True, this violates transparent persistence, however, it is technically pure.

        Sun JDO can not get around the problem of completely eliminating JDOHelper.makeDirty. So, Sun JDO is not truely transparent persistence. And you wisely added retrieve(). In my view, you are already there.

        Personally, I use an enhanced -) Sun JDO interface (with the above methods) to wrap the non-PersistenceCapable mechanisms (JNDI, XMLEncoder, Serialization, Apache OJB, etc).

        Until Sun updates the JVM, this is the only technically pure route and ensures my objects can run agains any persistence capable mechanism. I think you guys have done an excellent job developing an API and are 99% there. If Sun added the JVM hooks to support hollow and dirty, you would have a universal peristence interface that could be used with all persistence mechanisms. Until then, it will be viewed by many that Sun JDO is dissing the non PersistenceCapable implementations. Make those simple changes to the API and the Sun JDO interface will become the universal standard.