My response Make JDO the "P" in CMP to Bruce Tate's article For JDO, the Time Is Now generated some interesting responses of its own.

There is a lot of passion in the Java community sorrounding Entity Beans, and I sense that we could direct that passion towards the development of a much improved and more comprehensive specification.

There are many aspects to persistence, and I believe that the community of Java programmers will be best served by solutions that allow us to pick and choose the aspects that are most suitable for our projects.

Some projects are stand-alone, and are not dependent on legacy Relational Databases. In the past, proponents for these applications rose up and banned the inclusion of an Object/Relational mapping standard in the JDO specification because they did not want their persistence options limited.

I think that this reaction was a mistake, and I suggest that we approach this issue from a different perspective. Reliance on a preexisting RDBMS is an undeniable aspect of some programs. If that aspect applies to your program, then you should enable the O/R mapping aspects of the specification. If your project doesn't need to interact with an RDBMS, then select whatever aspects of Persistence that you need.

What are the aspects of Persistence that are currently available?

• Maintenance of State between program invocations is the simplest aspect of persistence. This could be implemented in many ways, from simple serialization to much more robust solutions, but basically your only concern is that the state of an object is not lost.
• Container Managed Persistence is a control simplification aspect for many programs. When does the state need to be stored? When does it need to be restored? WIth a standard interface for your objects you can leave these and other details to the "container".
• Transactional Support is another aspect that is important to many. It may be important that a sequence of steps complete successfully or all changes are rolled back.
• Caching is another aspect, primarilly concerned with performance.
• Clustered (Distributed) Caching is an important aspect for applications that are distributed across multiple nodes. To some applications this is very important, to others it is moot.
• Object Relational Mapping, which I've previoulsy mentioned, is also a key aspect of many programs. There are many ways of implementing this feature, but surely a standard for specifying the mapping would be beneficial to all.
• XML mapping or Object mapping of one form or another can also be a key aspect of persistence. Once again, there would be no need to reinvent the wheel each time an application is written if standard solutions could be applied.

I'm sure I've left out some very important aspects, but you get the idea...

It's clear to me that neither Entity Bean CMP or JDO are exactly what I am looking for. From what I have heard, the AOP plans of JBOSS seem close, but even there I am not all that interested in a product specific offering. I'd like to see an "open" aspect-oriented persistence specification as a key part of the J2EE specification.