help for serialization with final member

[Pat Farrell]

I've got a class that I'm trying to write manual serialization code. I can't figure out how to handle the "final Person" member.
I can't do a set in the readObject function, since its final

public class SmartList<T extends TypedPart> implements Serializable {

/**  the User or Person */
protected final Person ourPerson;
protected ArrayList<T> theList;

I don't want to let the default implementation of readObject do its thing, because I don't want to serialize the whole Person, I'd rather just serialize its primary key (a Long) and recreate it on the fly. This is to avoid getting into a serialization loop, as a Person has a SmartList, which contains a reference to a Person, who has a SmartList....

How do I do this?

thanks
pat

[Leandro Coutinho]

You said that Person has a SmartList. So to avoid the serialization loop, set the SmartList in the person object to null.
I think it will work.

[Pat Farrell]

Leandro Coutinho wrote:You said that Person has a SmartList. So to avoid the serialization loop, set the SmartList in the person object to null.

I don't want it to be null, I want to have values in it.

So I need to be able to assign values in the readObject class to variables that are final.
This seems to be impossible.

[Campbell Ritchie]

Wait until somebody like Rob Prime is around, who will probably know how to use the readResolve method for that.

[Rob Spoor]

Actually I don't...

You can disable the default serialization of a field, either by making it transient or by explicitly specifying the ObjectStreamFields, but both will not restore it when deserializing. Since the field is final that means it will remain null indefinitely.

Perhaps you can get some results using writeReplace and readResolve as Campbell suggested; I haven't got much experience in these except for using the latter for maintaining Singleton instances properly for Serializable classes. Or perhaps it's even easier using readObject and writeObject; if you simply do not call stream.defaultReadObject and stream.defaultWriteObject it will not use the default serialization mechanism but your custom serialization instead. However, the final member will not be deserialized and will remain null...

Frankly, final fields and custom serialization are often a pain to combine, and often you need to drop one of the two.


However, Pat, you do realize that objects will not be serialized more than once, even if more references to it are serialized? The serialization mechanism will detect the object has been serialized already, and will store a reference to that serialized object instead of the object itself.

[Campbell Ritchie]

If Rob doesn't know, it must be difficult. There is a serialization section in Effective Java, 2nd edition, try page 302. It is too long to copy, but it goes on about defensive writing of readObject methods. It does not suggest there is any problem about serialising with final fields.

I have no idea whether this is of any use to you, or a waste of time. Sorry.

[Rob Spoor]

Campbell Ritchie wrote:If Rob doesn't know, it must be difficult.

You give me too much credit.