On Jue, 13 de Enero de 2005, 7:37, Vadim Gritsenko dijo: > Niclas Hedhman wrote: >> 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.
Yes. As told before, I have plans to do that too. ;-) Best Regards, Antonio Gallardo
