Why is Serialversionuid long in java?

Question

while i searched a lot but unable to find a reasonable answer for the same. Why can't serialversionuid be double? Any specific reason for keeping serialversionuid long?

Answer 1

A unique id is typically a randomly chosen whole number. e.g. UUID is two long values.

Using a double is much harder as not all 64-bit values are used in Java, and some values are not equal to themselves e.g. Double.NaN.

BTW if you really want to use a double you could do this

private static final long serialVersionUID = Double.doubleToRawLongBits(1.28);

But I don't know what value using a floating point value would have. If you want to encode a version number you can do this

private static final long serialVersionUID = MAJOR * 1000 + MINOR;

Answer 2

A UID is something that has to be unique in a given context for serialization, since it generally computed by IDEs or the programmer when creating an instance of Serializable. For something that should be unique, the long data type seems reasonable. Reasonable because, it is an implicit datatype and is the biggest one available along side double. The bigger the data type, the lower the chance of conflict in generating the Unique ID. (Imagine using byte as the data type for serialVersionUID. You would have only 256 available values for generating "Unique" IDs which would lead to a lot of conflict). The double data type has its own problems for comparison with other double values. long has no such issues. On the other hand, using a String or other reference types may not be suitable as it might be expensive in terms of space and time complexities. All these reasons make long a reasonable choice for using it as the data type for serialVersionUID.

Refer to this article for more information. I've also extracted some bits from the same.

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. Array classes cannot declare an explicit serialVersionUID, so they always have the default computed value, but the requirement for matching serialVersionUID values is waived for array classes.

Hope this helps!