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:
-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).
-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.