45

I'm extending a class (ArrayBlockingQueue) that implements the Serializable interface. Sun's documentation (and my IDE) advises me that I should set this value in order to prevent mischief:

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.

Now, I couldn't care less about what value to put in there. Does it matter?

Hanno Fietz
  • 30,799
  • 47
  • 148
  • 234

2 Answers2

76

No - so long as you change it at the right time (i.e. when you make a change which affects serialization, e.g. removing a field) it shouldn't matter what value you use.

For simplicity I'd suggest starting with 0 and increasing it by 1 each time you need to.

The serialization spec has more details.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • 1
    Sorry Jon, the link points to an non-existant document (Granted it's over 2 years later). – Buhake Sindi Sep 06 '11 at 07:38
  • @The Elite Gentleman: Thanks, have edited to point at the Oracle server. – Jon Skeet Sep 06 '11 at 08:14
  • 1
    Shall I understand that two different classes (e.g. MyJLabel and MyEncoder) could use the same value of `serialVersionUID` and be properly deserialised? I would assume that yes, as the names are different, it should only be a matter of version. – Matthieu Feb 17 '14 at 15:10
  • 1
    @JonSkeet, are you saying that if `class A` has a `serialVersionUID` of 0 and you change the class without changing the SVUID, you will get an error? Or you won't? The docs seem to state the only way to avert the error is by keeping the SVUID the same throughout different versions of the class (`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.`). The end goal is to _avoid_ errors when you have a structural change to the class, right? – ryvantage Jul 15 '15 at 17:00
  • 5
    @ryvantage: If you explicitly set an id but don't change it when you should, and then send data from an old version to the new version or vice versa, you'll probably end up with silently corrupt data or an unclear error message. Don't do that. The aim is to not only avoid errors, but also to provoke errors where you're doing something unsafe. – Jon Skeet Jul 15 '15 at 17:02
  • Removing a field does not adversely affect serialization, and is not a reason to change the `serialVersionUID`. Neither does adding a field. See the Object Versioning chapter of the Object Serialization Specification. – user207421 May 24 '22 at 07:20
  • @user207421: Removing a field is explicitly called out as an incompatible change in the serialization spec. – Jon Skeet May 24 '22 at 07:43
13

The only thing that matters for the serialVersionUID is that binary-compatible serialized versions of the class have the same serialVersionUID; that is if you've not made any breaking changes to the serialized form of the class it'll be fine.

Of course, a better option is to use the advanced options that serialization makes available to you so that there are never any breaking changes. I'd suggest reading about readResolve() et al. Effective Java covers some of the thornier issues in this area in detail.

GaryF
  • 23,950
  • 10
  • 60
  • 73