Java Reference
In-Depth Information
As mentioned previously, information pertaining to the object's state is persisted to a file
via a stream of bytes. But that is not all of the information that is saved. Information regarding
the class type and its version number is also persisted. This is important because the class
loader needs to properly deserialize the class from its persisted state. If the
serialVersionUID
is not declared, then the
ObjectOutputStream
will generate a unique version number for the
class. Any subsequent changes to the class's members will generate a new version number at
the next compilation. In the
sampleproject.db.DVD
class, the version ID is defined as a private
member defined as follows:
private static final long serialVersionUID = 5165L;
Note
Often, serialization compatibility between versions needs to be maintained even though minor
changes that will not break serialization compatibility have occurred. In these situations you need to declare
the
serialVersionID
. You can use
serialver
to do this initially. This will allow you to define your own
numbering schemes for the
versionID
for the class. Interestingly, even though this is a private field, the
JVM knows it is there and uses it when defining a class.
■
Tweaking the Default Serialization Mechanism
There may be times when you want more control over how an object's state is serialized. For
instance, perhaps you are only concerned with persisting part of the object's state, but not all
of it. This is useful if the class contains a private member for holding a reference to a database
connection, and you do not want to persist that information because the connections are only
meaningful during a single session and are assigned on an as-needed basis. It wouldn't make
sense to try to persist a database connection for the next time the application is run. The next
time you load the object with the connection reference, you can simply assign that member a
new connection. Another situation where you would not want to persist object information is
when an object member is of a type that is not serializable. For instance, in our sample project
the J2SE 1.5
Logger
instance in the
DVD
class is not serializable.
But how do we indicate to the JVM that we don't want to persist a specific class member
but would like to persist the other class members? Java provides for this functionality through
the use of the keyword
transient
. The byte stream that gets persisted will not include any
members that are declared using the keyword
transient
.
We use the keyword
transient
in our serialization implementation since the
Logger
instance cannot be serialized. (Hint: Try running
serialver
on the logger.) Conceptually this
works out well since a logger member does not really add anything essential to the notion of a
DVD. In general, a logger is the sort of thing that does not need to be persisted, and we can re-
create a complete DVD record by reinitializing the logger. The following is an example of how
you can use the keyword
transient
in the
Logger
instance in
DVD.java
:
private transient Logger log = Logger.getLogger("sampleproject.db");
There is another approach to serialization that we should mention. Rather than imple-
ment
Serializable
, an alternative approach is to implement a subinterface of
Serializable
:
