On Feb 20, Bryce McKinlay wrote:
> Eric Arseneau wrote:
>
> > > Since the computed values are the same as the explicitly set ones
> > > I am wondering if we could not just remove them. It might hide bugs.
> > > What do people think about it?
> >
> > You will find that for now the values may be the same, but if the algorithm
> > changes later, or use on a different VM that the result is not the
> > same. [...]
>
> The algorithm for calculating the UID is explicitly specified as part of the
> serialization specification, isn't it? [...]
Yes it is.
> I don't think that classes that do not have readObject()/writeObject() should
> have an explicit SerialVersionUID. If a VM is calculating a different UID for
> the class, then either the serialized form really isn't the same (in which
> case the UIDs MUST be different), or the serialization implementation is
> broken.
The serialVersionUID doesn't only depend on the serialized fields, but
also on the non private methods and non private static/transient
fields. So if you add a method, the UID changes, while the serialized
form keeps the same.
Normally exceptions have a very canonic set of methods, so relying on
the default UID is quite safe. But IMHO the existance of an explicit
serialVersionUID in a serializable class is a good indicator that
someone checked that the serial form is correct.
Jochen
_______________________________________________
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath