Re: Problems retrieving object through rmi
Esmond Pitt wrote:
Nigel Wade wrote:
But don't forget that you are now responsible for maintaining the UID. If you
change the class in any meaningful way (such that the data which is
serialized
will be different) then you should update the serialVersionUID. The prevents
a
class with one UID attempting to de-serialize objects with a different UID,
and
hence incompatible contents.
No no no. That will break your downward compatilibity.
Yes, yes, yes. If you break the backwards compatibility then you must change the
UID, or face the consequences.
Serialization
already supports versioning to a great extent. As long as you stay
within the rules there is no need to change the serialVersionUID at all
and it is a practice to be actively discourage. The applicable rules are
defined in the Serialization Specification but they amount basically to
not deleting fields, not changing inheritance, and not change the types
of fields. There's an awful lot you can accomplish within those limits.
If you have to go outside them you should then use one of the available
serialization mechanisms to render the new class
serialization-compatible with the old one, and there is an awful lot
more you can do within these mechanisms.
What I said was that if you change the contents of the serialized object then
you must manually alter the UID. That remains valid no matter how many rules
and tools you use to try to circumvent it.
If you *want* to break backwards compatibility, and lose contact forever
with any persistent serializations you may have done, then change the
serialVersionUID. Not otherwise.
Like I said...
--
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : nmw@ion.le.ac.uk
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555