On Wednesday 12 January 2005 06:14, Vadim Gritsenko wrote:
Even though above classes are Serializable, none of those classes have
witeObject / readObject methods. Next change to any of those classess will
cause exceptions during serialization, if somebody to try it.
serialVersionUID should be removed.
This is not a true statement.
Ok, "next incompatible change" - that's what I meant.
By having serialVersionUID explicitly declared, instead of the automatically generated number from the class' signature, means that any compatible change can be made without serialization exceptions.
For instance,
if you add methods --> serialVersionUID not present == exception
serialVersionUID present == no problems.
if you add fields -->
serialVersionUID not present == exception
serialVersionUID present == fields with no values in the stream are not assigned, values in the stream for which there are no fields are ignored.
Generally speaking, if you add "implements Serializable" to a class, you should also add the serialVersionUID, and == 1 is good enough.
I am of opposite opinion. If no effort is made to preserve compatibility, no serialVersionUID should present. Moreover, serialVersionUID should be added only when making incompatible change and doing an effort to preserve compatibility.
If serialization compatibility is essential between versions of the application, then it is strongly recommended that readObject and writeObject methods are also added, since you have better control of how to deal with differences.
Here, I'm in agreement.
Vadim
