Java - serialversionuid

Question

Hi all,

Why isn't the serialversionuid automatically generated? I was running into an issue on an application server where apparently an old class was being cached.

Walter

Answer 1

It is automatically generated, based on the structure of the class. If the structure changes, the id is regenerated (according to the serialization specification it is a hashof the class).

So you'd better define an explicit serialVersionUID.

Answer 2

If you're using Eclipse as your IDE, you can right-click on the warning about the missing serialVersionUID and you'll get two options:

1) Define the Eclipse default, which has the value 1L; or
2) Define a randomly generated long value

If you care about versioning of serialized objects, you'll need to manually regenerate a new value each time you modify the class. The Javadoc for the Serializable interface has this to say about what happens if you don't declare a serialVersionUID at all:

If a serializable class does not explicitly declare a serialVersionUID, then the serialization runtime will calculate a default serialVersionUID value for that class based on various aspects of the class, as described in the Java(TM) Object Serialization Specification. However, it is strongly recommended that all serializable classes explicitly declare serialVersionUID values, since the default serialVersionUID computation is highly sensitive to class details that may vary depending on compiler implementations, and can thus result in unexpected InvalidClassExceptions during deserialization. Therefore, to guarantee a consistent serialVersionUID value across different java compiler implementations, a serializable class must declare an explicit serialVersionUID value.

In practice, I've found that even if you start with identical source code on two or more machines (checked out of Subversion, for example) where serialVersionUID was undefined in a class, the compiler-generated value in the class is different on each machine when the code is compiled. This can cause confusing errors during development.

If you are sure that you'll never have a situation where you have stale serialized objects that are out-of-sync with a newer version of the class (or two JVMs sending out-of-sync serialized objects to each other, perhaps across a network or socket connection) then just set a value of 1L for serialVersionUID and leave it that way forever.

http://download-llnw.oracle.com/javase/6/docs/api/java/io/Serializable.html

Answer 3

serialversionuid is not automatically generated because it is dangerous. When serialversionuid is set, it implies that two versions of a class are compatible with respect to serialization.

Imagine you have a class called Foo, and it has NO serialversionuid (the default), and you serialize an instance of Foo to a file. Later, you add some new members to the Foo class. If you try to deserialize the Foo object from the file, you will get a serialization failure stating that the objects are incompatible. They ARE incompatible, this is want you WANT and is the default. They are incompatible because new members in the Foo class cannot be initialized from the old serialized instance of Foo.

Now, you might say, "I don't care, in my application it is acceptable for those fields to be uninitialized". If that REALLY is the case, you can set the serialversionuid of the NEW Foo class to be the same as the OLD Foo class. This will tell Java that the objects are compatible with respect to serializablity, and Java will not complain when you deserialize the old Foo instance into the new Foo class (but the new fields will still be uninitialized).

If you are creating a new class for the first time, and you set the serialversionuid, YOU ARE ENTERING A CONTRACT. You are saying, "For all future versions of this class with the same serialversionuid, I will guarantee they are compatible with respect to state and serialization".

If you change a class, and you EXPLICITLY want to DISALLOW deserialization of old versions, you can change the serialversionuid to a new value. This will cause an exception to be thrown if an old object is attempted to be deserialized into a new class instance.