SerialVersionUID In Java

SerialVersionUID In Java

Java serialization mechanism writes the metadata of the object, which includes the class name, field names and types, and superclass. This class definition is stored as a part of the serialized object. On the other hand deserialization process to reconstitute the objects and map the stream data into the class attributes with the appropriate type.

Everytime when an object is serialized the java serialization mechanism automatically computes a hash value. ObjectStreamClass's computeSerialVersionUID() method passes the class name, sorted member names, modifiers, and interfaces to the secure hash algorithm (SHA), which returns a hash value.The serialVersionUID is also called suid.
So when the serilaize object is retrieved , the JVM first evaluates the suid of the serialized class and compares the suid value with the one of the object. If the suid values match then the object is said to be compatible with the class and hence it is de-serialized. If not InvalidClassException exception is thrown.

Changes to a serializable class can be compatible or incompatible. Following is the list of changes which are compatible:

• Add fields
• Change a field from static to non-static
• Change a field from transient to non-transient
• Add classes to the object tree

List of incompatible changes:

• Delete fields
• Change class hierarchy
• Change non-static to static
• Change non-transient to transient
• Change type of a primitive field

So, if no suid is present, inspite of making compatible changes, jvm generates new suid thus resulting in an exception if prior release version object is used .

The only way to get rid of the exception is to recompile and deploy the application again.

If we explicitly mention the suid using the statement:

private final static long serialVersionUID = <integer value>

then if any of the metioned compatible changes are made the class need not to be recompiled. But for incompatible changes there is no other way than to compile again.