What means 1L serialVersionUID? When could I use this default value 1L?

Question

There are 3 ways to define the serialVersionUID :

1. private static final long serialVersionUID = 1L; (Default)
2. private static final long serialVersionUID = -         


        

Answer 1

Imagine you write a class with a serialVersionUID, instantiate it, then serialize it to a file (with ObjectOutputStream)

Then you modify the class.

Then, with the modified class, you deserialize (read in) the version you serialized before modification. Java will check the serialVersionUID of the current class and the serialized class, and if they don't match, the deserialization will fail. This is a deliberate fail-fast to prevent much more subtle (and harder to debug) errors occurring later on due to class version incompatibilities.

If you omit serialVersionUID then you disable the version checking. If you always set if to 1L, then the check will always pass (the value is always the same) so you are still vulnerable to subtle class version incompatibility problems.

Answer 2

What is the meaning? Is that useful?

Yes. The point of serialVersionUID is to give the programmer control over which versions of a class are considered incompatible in regard to serialization. As long as the serialVersionUID stays the same, the serialization mechanism will make a best effort to translate serialized instances, which may not be what you want. If you make a semantic change that renders older versions incompatible, you can change the serialVersionUID to make deserializing older instances fail.

If all classes have the same serialVersionUID 1L, is there no problem?

No - the serialVersionUID is per class.

Answer 3

This is explain here:

The serialVersionUID is a universal version identifier for a Serializable class. Deserialization uses this number to ensure that a loaded class corresponds exactly to a serialized object. If no match is found, then an InvalidClassException is thrown.

---

From the javadoc:

The serialization runtime associates with each serializable class a version number, called a serialVersionUID, which is used during deserialization to verify that the sender and receiver of a serialized object have loaded classes for that object that are compatible with respect to serialization. If the receiver has loaded a class for the object that has a different serialVersionUID than that of the corresponding sender's class, then deserialization will result in an InvalidClassException. A serializable class can declare its own serialVersionUID explicitly by declaring a field named "serialVersionUID" that must be static, final, and of type long:

---

Useful Links

1. java.io.Serializable
2. Why should I bother about serialVersionUID? (StackOverflow)
3. serialVersionUID in Java Serialization

Answer 4

You can assign any long value to serialVersionUID, but you have to change it every time you modify your class.

The second looks like a generated serialVersionUID, based on the features of the current class version.

Answer 5

The value is used while serializing an object and de-serializing the object back into JVM.

Further, If your class changes and you don't want to support backward compatibility (i.e. able to de-serialize the object back which was serialized using your last version of class) you can change the version number to any other value.

However, to support the backward compatibility you need to keep the same version number as previously set value of serialVersionUID.

The best practice is to change the serialVersionUID, every time you have some incompatible changes to the class.

Answer 6

The JVM will throw a InvalidClassException if the serialVersionUID of a serialized object does not match the serialVersionUID of the class it is being deserialized as.

The serialVersionUID of a class should change every time the class changes in an incompatible way. Normally this means every time you change the shape of a class (ie fields or methods change).

There are some cases where you don't want the serialVersionUID to change. For instance you might accept old versions of the object into your application. In this case, you can leave the serialVersionUID the same and new fields will come through as null.