Serialization reminder
Warren Levy
warrenl@cygnus.com
Sat Aug 5 22:50:00 GMT 2000
My apologies to those who are seeing this twice. I should have sent it to
this list in the first place but I had instead just replied to a prior
thread (which was on java-patches).
--warrenl
---------- Forwarded message ----------
Date: Sat, 5 Aug 2000 22:30:41 -0700 (PDT)
From: Warren Levy <warrenl@cygnus.com>
On 5 Aug 2000, Tom Tromey wrote:
> 2000年08月05日 Tom Tromey <tromey@cygnus.com>
>> * java/io/PrintWriter.java: ...
> (out): Now protected, to match spec.
What I'm about to say does not affect PrintWriter, as it isn't
serializable, but seeing the ChangeLog entry is prompting me to make the
following reminder for other classes (which *are* serializable).
When making changes to serializable classes in libgcj, please be aware
that changes to the class signature (i.e. modifers and interfaces
implemented), non-private method & constructor signatures, and ALL fields
(except 'private static' and 'private transient') WILL affect the SUID
(serialVersionUID) calculated for the class.
The SUID value is used in the versioning of serialized objects and having
a different value than what the JDK is expecting will typically cause
those serialized objects to be rejected by programs run with Sun's (and
possibly others') implementations.
In cases where there is a change to the spec between JDK 1.1 and 1.2 that
does not have a material effect on the usability of the serialized data, I
believe, Sun forces the use of the 1.1 SUID by explicitly including the
SUID in the class, e.g.:
private static final long serialVersionUID = 7818375828146090155L;
The SUID value can be determined for any version with the JDK by running
Sun's 'serialver' utility, or using the ObjectStreamClass method
getSerialVersionUID(). I have a version of serialver for libgcj that I'll
be checking into the tree for everyone's use; now that serialization is
working pretty well, I'll check that in RSN.
This is an important issue to consider even if we follow the spec, since
there are times when an implementation of a class can wind up with a
different SUID than Sun calculates. So when writing new serializable
classes (or modifying existing ones) please take a moment to make sure
that the SUIDs match. If they don't, please recheck the 1.1 spec to see
what differences might cause the discrepancy, fix them (except changes
called out by the 1.2 spec!), check the class against the Serialized Form
doc:
http://java.sun.com/products/jdk/1.2/docs/api/serialized-form.html
write any necessary readObject and/or writeObject methods that might be
indicated by the Serialized Form), and finally, if the SUID still
doesen't match, explicitly set the serialVersionUID in the class
IFF the class is indeed compatible from a serialization standpoint.
It is best if you could test the class too by serializing objects of the
class and seeing that they are deserialized properly by other
implementations and vice versa with libgcj.
For details on serialization, check out the spec at:
http://java.sun.com/products/jdk/1.2/docs/guide/serialization/
Ok, I'll get off the soapbox now ;-).
--warrenl
More information about the Java
mailing list