InvalidClassException and serialVersionUID in Java

InvalidClassException and serialVersionUID in Java

When you implement java.io.Serializable interface to make a class serializable, the compiler looks for a static, final field named "serialVersionUID" of type long. If the class doesn't have this field declared explicitly then the compiler will create one such field and assign it with a value which comes out of a implementation dependent computation of serialVersionUID. This computation depends upon various aspects of the class and it follows the Object Serialization Specifications given by Sun. But, the value is not guaranteed to be the same across all compiler implementations.

This value is used for checking the compatibility of the classes with respect to serialization and this is done while de-serializing a saved object. The Serialization Runtime verifies that the serialVersionUID of the sender class (which was used for saving the state of the object on the stream) and that of the receiver class (the class which is being used to restore the object, possibly at some other system) both are exactly same. If the receiver system has loaded the class having some other serialVersionUID than that of the class used while serialization process then we get an InvalidClassException.

Caution: It's highly recommended that you explicitly declare and initialize the static, final field of type long and named 'serialVersionUID' in all your classes you want to make Serializable instead of relying on the default computation of the value for this field. This computation is extremely sensitive and may vary from one compiler implementation to another and hence you may turn up getting the InvalidClassException even for the same class just because you used different compiler implementations on the sender and the receiver ends of the serialization process.

In most of the cases you would be using 'private' access specifier only for this field as the declaration normally applies only to the class declaring it and we don't really need to either inherit this field in the subclasses OR to access it from outside. So, there is hardly any reason why we shouldn't keep it 'private'.