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.

BECOMING PERSISTENCE-CAPABLE

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.