TechLists.org

If I mark the value transient and serialise the class to disk, it will be
reloaded as null.  I believe this violates the principle of least surprise.


> 	If you want to reinitialise when you deserialise, 
> then what is the point of saving the object or even implementing
> Serializable? You could just save the constructor parameter 
> values and the class name, in most cases.

I think this is an overly simplistic view of my class. ;)  The class itself
-does- have state that I want to store.  It also has state that I do not want
to store, but that I want to be defined (and not simply be 'null' and beyond my
control)

Here is another interesting problem I ran into with this type of situation.

If you:

	public final transient HelperStateObject objState = new HelperStateObject();

Once the object is (de)serialised, you will never be able to usefully use
objState again  (It will be null and there is no way to change this).  Quite
clearly, the intention is for this state to be the 'default' state for the
object.  It is not intended to be part of the serialised state of the object
(and I think requiring this to be so is excessive).

I think that this, even in itself, is a fairly clear argument that the
serialisation system had not been (fully) explored prior to release.  If this
limitation was their intention, they could at least give me a compile error or
warning. ;)


Paul


---
To unsubscribe, mail advanced-java-unsubscribe@xxxxxxxxxxxxxxxx
To get help, mail advanced-java-help@xxxxxxxxxxxxxxxx