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.