On Jue, 13 de Enero de 2005, 14:32, Niclas Hedhman dijo:
> 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.
> 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.
> 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.

Thanks for the better explanation. :-D

As I told before, I am planning to add new changes on the serialization
side including writing read/write Object methods. I believe this could
make it a little bit more stable as is part of write health code.

Best Regards,

Antonio Gallardo

Reply via email to