Why Generate Long Serialversionuid Instead of a Simple 1L

Why generate long serialVersionUID instead of a simple 1L?

As far as I can tell, that would be only for compatibility with previous releases. This would only be useful if you neglected to use a serialVersionUID before, and then made a change that you know should be compatible but which causes serialization to break.

See the Java Serialization Spec for more details.

Is Java SerialVersionUid of 1L ok? Or does it need to be unique?

The class name is part of the serialized representation of an object. The serialVersionUID is only used for versioning the classes. So 1L is a valid value.

Note that if you don't plan to maintain the compatibility of serialization while evolving the class, serialVersionUID is useless, and you can just omit it. Having a serialVersionUID is useful when you want to make compatible changes to a class and still be able to read objects that were serialized using an older version of the class (or vice-versa). But that requires extreme care, and is far from being an easy task. You should generally avoid using serialization for long-term storage. If used for networking purpose, using the same exact classes for the client and the server (i.e. deploying both at once) is the easiest strategy.

Also note that you could easily prove your coworker that he's wrong by simply serializing and deserializing two objects of two different classes having both the same value (1L) as serialVersionUID. If his theory was true, the JVM would have no way of knowing how to deserialize the objects.

What is a serialVersionUID and why should I use it?

The docs for java.io.Serializable are probably about as good an explanation as you'll get:

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:

ANY-ACCESS-MODIFIER static final long serialVersionUID = 42L;

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. It is also strongly advised that explicit serialVersionUID declarations use the private modifier where possible, since such declarations apply only to the immediately declaring class — serialVersionUID fields are not useful as inherited members.

Why serialVersionUID is of type long for Serializable classes

The type of serialVersionUID should be long because that is how it was specified. See http://docs.oracle.com/javase/8/docs/platform/serialization/spec/class.html (specifically section 4.6)

The reason that the UID is 64 bits is that the risk of accidental UID collision would be too high if (say) 32 bit values were used.

The default serial version UID generation scheme creates a hash based on classes methods and fields. There is a small, but non-zero, that two different classes will have the same default UID. If this happens, then the deserializer may not notice that serialized form of the object is incompatible with the slass we are trying to deserialize to. Bad things would then happen.

If 32 bit UIDs were used, the chance that two incompatible classes had the same UID would be one in 2³². That is about one chance in 4 billion. That is too large a chance. With 64 bit UID values, the change is one in 2⁶⁴. That is about one chance in 16 quadrillion. That was deemed (by the designers) to be an acceptably small probability.

Should serialVersionUID be unique for different classes?

Yes, you can. Serial versions of different classes are independent and do not interfere each other.

PS

Eclipse even proposes you to set serialVersionID by default value that is 1L.

Is there a reason to use a real serialVersionUID?

The only use of a "real" serialVersionUID is for backword compatibility. If it is a new class, use whatever numbering system you want.

Personally I think using a simple number scheme will make it easier to read and compare changes of that number between versions. The hash value creating by the tooling is fine for a machine, but not human friendly. A simple one up numbering scheme works great for both, after all, the machine doesn't care one way or the other.

---

Related Topics