When a class is undergoing a period of evolution, particularly a
class being used in a networking context such as RMI or servlets, it
may be useful to provide a serialVersionUID
value
in this class. This is a long integer that is basically a hash of the
methods and fields in the class. Both the object serialization API
(see Section 9.17) and the JVM, when asked to cast
one object to another (common when using collections, as in Chapter 7), either look up or, if not found, compute
this value. If the value on the source and destination do not match,
a ClassCastException
is thrown. Most of the time,
this is the correct thing for Java to do.
However, there may be times when you want to allow a class to evolve
in a compatible way, but you can’t immediately replace all
instances in circulation. You must be willing to write code to
account for the additional fields being discarded if restoring from
the longer format to the shorter, and having the default value (null
for objects,
for numbers and false for boolean) if restoring from the shorter
format to the longer. If you are only adding fields and methods in a
reasonably compatible way, you can control the compatibility by
providing a long int
named
serialVersionUID
. The initial value should be
obtained from a JDK tool called serialver, which
takes just the class name. Consider a simple class called
SerializableUser
:
/** Demo of a data class that will be used as a JavaBean or as a data * class in a Servlet container; making it Serializable allows * it to be saved ("serialized") to disk or over a network connection. */ public class SerializableUser implements java.io.Serializable { public String name; public String address; public String country; // other fields, and methods, here... }
I first compiled it with two different compilers to ensure that the value is a product of the class structure, not of some minor differences in class file format that different compilers might emit:
$ jikes +E SerializableUser..java $ serialver SerializableUser SerializableUser: static final long serialVersionUID = -7978489268769667877L; $ javac SerializableUser.java $ serialver SerializableUser SerializableUser: static final long serialVersionUID = -7978489268769667877L;
Sure enough, the class file from both compilers has the same hash.
Now let’s change the file. I go in with a line editor and add a
new field phoneNum
right after
country
:
$ ed SerializableUser.java 383 8 public String country; a public String phoneNum; . w 408 q ian:145$ jikes +E SerializableUser.java ian:146$ serialver SerializableUser SerializableUser: static final long serialVersionUID = -8339341455288589756L;
Notice how the addition of the field changed the
serialVersionUID
! Now, if I had wanted this class
to evolve in a compatible fashion, here’s what I should have
done before I started expanding it. I copy and paste the original
serialver output into the source file (again using
a line editor to insert a line before the last line):
$ ed SerializableUser.java 408 $i static final long serialVersionUID = -7978489268769667877L; . w 472 q $ jikes +E SerializableUser.java $ serialver SerializableUser SerializableUser: static final long serialVersionUID = -7978489268769667877L; $
Now all is well: I can interchange serialized versions of this file.
Note that serialver is part of the “object
serialization” mechanism, and therefore only works on
classes
that implement the Serializable
interface
described in Section 9.17.
18.219.71.21