Remote Method Invocation and Object Serialization - Java: The Good Parts - page 152

reasons. The first was that it violated notions of security in the Java platform; when an object
was serialized, its internal state could be observed (and, perhaps altered) outside of the usual
security context of the Java Virtual Machine. Perhaps as important was the realization that de-
claring an object to be Serializable while not requiring that any methods be implemented
did require the programmer creating the class to reflect on what that declaration entails.
One such implication is relevant from the start. If a class is marked as Serializable , the
programmer constructing the class needs to ensure that either all parts of the object are them-
selves Serializable or are marked as excluded from the serialized state of the object. When
we first made our PlayerImpl class implement Serializable back in Chapter 5 , the fields
of the class contained all primitive types or were of type String , which is itself Serializ-
able . But when we added the various roles to the class in Chapter 8 , we added fields that refer
to classes that are not themselves Serializable . At the moment, none of the classes Bat-
terImpl , FielderImpl , or CatcherImpl is Serializable . As things stand, any attempt to
serialize a PlayerImpl object will throw a NotSerializableException .
We can deal with this in one of two ways. The first is useful when you are dealing with parts
of an object's state that make sense only within the context of a particular virtual machine.
For example, it is often convenient to store a file handle within the state of an object. But
file handles are relative to a particular run of a program on a particular virtual machine; re-
constructing the file handle in some other virtual machine doesn't really make sense and will
result in trouble. For such fields, you can mark the field using the Java keyword transient ,
which will tell the object serialization system that the field should not be part of the serialized
state of the object. Of course, when such an object is deserialized, it is up to the class to fill in
some default value for the field.
But this is not the case with our BatterImpl , FielderImpl , and CatcherImpl objects. Each
object contains information that will make sense if copied to a different machine (or copied
to the same machine at some other time), so we would like these to be part of the serialized
state of the PlayerImpl object. That means we need to mark each of these classes as Seri-
alizable as well. This is pretty simple; all we need to do is add java.io.Serializable to
the list of interfaces each of these classes implements. When we do that, we should also make
sure that all of the fields of these newly Serializable classes are themselves Serializable ,
and if not, we continue the process. Lather, rinse, repeat.
Well, almost. The perceptive reader will notice that we also add a private static final
long field called serialVersionUID to each of these classes. The serialVersionUID is a
remnant of an early attempt to deal with the versioning problem with Java classes. It is still