15

EDIT: By random I mean a large computed number with no semantic meaning to us as developers

When implementing the Serializable interface its best practice and really important to specify a serial version UID. In numerous places, I often see random numbers being used. E.g.

Effective Java (2nd edition) pg 312:

private static final long serialVersionUID = 234098243823485285L;

From the String class in Java 6:

private static final long serialVersionUID = -6849794470754667710L;

From the ArrayList class in Java 6:

private static final long serialVersionUID = 8683452581122892189L;

etc. Even eclipse offers the option to generate these random numbers (though the primary default appears to be to generate a serialVersionUID of 1L)

Why use random numbers? Doesn't it make more sense to start at 1L and increment to 2L when it changes like any sensible revision control? The only time I can think of to use a seemingly random number is if you didn't specify a serialVersionUID to begin with and want to do so now (which ties you in to the run-time autogenerated version to provide backwards compatibility support).

Chris Knight
  • 24,333
  • 24
  • 88
  • 134
  • 1
    I don't think they're "random" numbers, they just seem arbitrary. They're probably some sort of hash of the members/methods in the class. A total guess, though. I have no information to support this statement. – Jon Newmuis Feb 20 '13 at 23:13
  • @JonathanNewmuis It is calculated based on method signatures and such. – JustinKSU Feb 20 '13 at 23:14
  • You're right as they are computed values, though as they have no meaning to us they are effectively random – Chris Knight Feb 20 '13 at 23:16
  • 1
    @BrianRoach Not exactly the same question, since that's just asking why anything other than `1L` should be used. – Paul Bellora Feb 20 '13 at 23:34

2 Answers2

12

Those "random" numbers are probably the numbers which would have been generated for the class automatically in its "current" form as per the Java Object Serialization Specification... where "current" is "current at the time serialVersionUID was first declared".

That would allow data which had been previously serialized to still be deserialized - while moving forward to a more explicit declaration of breaking changes in the future.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
4

They are almost certainly not random numbers, but rather the output of the serialver tool.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • 1
    Thanks and I understand this, but seeing these numbers in the code makes me wonder if all those classes forgot to specify the serialVersionUID in the first instance and are retrofitting them, or have explicity chosen the computed values (from serialver) at the start (and if so, why) – Chris Knight Feb 20 '13 at 23:26
  • 2
    @ChrisKnight Well there's no way of knowing, is there? My guess would be #2, especially as the code was probably written by technical writers and it still isn't a well-understood topic even by programmers even after 17 years. I usually use 1L or -1L and leave it that way forever. – user207421 Feb 21 '13 at 00:14