The advantage of the generated serialVersionID instead of 1L, 2L,

Question

I have a discussion with a colleague about serialVersionUID of serializable classes: it always starts with serialVersionUID = 1L , and then increments it by one when significant changes occur in the class.

JDK classes always seem to use the more complex, generated serialVersionUID, as in the java.lang.String class:

 private static final long serialVersionUID = -6849794470754667710L; 

Now my colleague asks about the advantages of this kind of serialVersionUID compared to the much simpler serialVersionUID, for example, 1L, 2L, 3L ...?

We also searched in SOF, but are not very happy with the answers, for example, Why generate a long serialVersionUID instead of a simple 1L? .

In my opinion, the advantage of using the generated identifiers is that it does not need version information for an older class. But when manually increasing identifiers, you should know the highest value so far. This may seem trivial (just by looking at the current serialVersionUID and increasing it by 1), but it can be more complex in large software projects, large development teams, or in distributed environments.

Answer 1

The advantage of using the generated one is that it is compatible with the previous version of the class if it ran without serialVersionUID in wild.

Having said that, your colleague is almost certainly mistaken in order to increase it. serialVersionUID should only be changed where you agree that the class has changed forever, and you intentionally want to introduce serialization incompatibility. The times when this happens in nature are rare, limited to cases where you change the inheritance of a class or types of member fields in an incompatible way. If you decided to create a Serializable class, you should already have adopted a mode in which this does not happen.

Answer 2

This is an interesting question to come to the point: I do not know.

SUID is part of the open API. After publishing an API that is used outside your control, like the JDK, you cannot change this number without breaking the compatibility.

Therefore, I do not see any advantage of using a number, for example, 32432544354343L instead of 1L.

But for internal development, I see a slight advantage starting with a number like 1L:

Suppose we have 3 banks of an RMI client-server application:

• client.jar
• server.jar
• api.jar

In api.jar there are such business classes as Song, Album, ... used by client and server, serialization.

Now we start with SUID 1L for some of these classes and after release we change the internal format of one of these classes, so we increase SUID to 2L.

Client and server components should now include the new api.jar. If we make a mistake and forget to update either the client or the server with the new api.jar dependency, there will be an exception during deserialization. The message in the exception will include incompatible SUIDs.

So, here the numbers 1L and 2L are in the message. 2L> 1L, so we know that the component uses the old api.jar. With the generated IDE numbers like 123434534553L and 654642646363L, we don’t know which component uses the old api.jar.

But on the other hand, even newer JDK classes like LocalDate use numbers like 123434534553L instead of a simpler one. There seems to be a mixture in apache commons-lang, like FastDateParser.java uses a simple 3L.

https://github.com/apache/commons-lang/blob/master/src/main/java/org/apache/commons/lang3/time/FastDateParser.java

Strange ...