Subject:   On becoming persistence-capable
Date:   2002-12-13 03:06:20
From:   robin@ogilviepartners.com
Response to: On becoming persistence-capable

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.

Full Threads Oldest First

Showing messages 1 through 1 of 1.

  • 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.