Re: detachable vs non detachable classes serialization compatible

[Craig L Russell]

Hi Erik,








Thanks,

Craig

On May 6, 2007, at 5:39 AM, Erik Bengtson wrote:

It would help if you could explain what you have in mind with this change. The decision to make the detachable serialization contract incompatible was deliberate, and the objective is to guarantee that attaching a detached instance behaves correctly. If you want a detached instance simply to send it away and never expect to see it again, your proposal might be of interest. Is that what you had in mind? Do you have some ideas on how to implement this feature? Seems that if the unenhanced class is given an input stream with the detached info in the serialized form of the instance, it's going to run into an exception (unless you modify the unenhanced class, perhaps with a byte-code enhancer).

Hi,


let the “jdoDetachedState” lose on unmarshalling.

From:

class be used wherever the instance might be instantiated."

To:

will occur on the unmarshalled instance."

Regards,

Erik Bengtson

The spec says classes that detachable and non detachable classes are not compatible intentionally. I would like to propose a change to this behavior and "Classes marked as Detachable are not serialization-compatible with un-enhanced classes. This is intentional, and requires that the enhanced version of the "Classes marked as Detachable are not serialization-compatible with un-enhanced classes. When unmarshalling a detached object with an un-enhanced version of the class, the detached state is dropped and no further read or change tracking

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature