1

What are the valid and invalid reasons for incrementing the version ID of a class definition that implements Serializable?

In other words what will introduce a write-then-read incompatibility? Is there any way that a change to a method can introduce an incompatibility? Is there any way refactoring can introduce an incompatibility?

Edit Reading the links and answers I see that the programmer defined ID is the way to take control of an automatic ID that makes objects too brittle. If I control the ID, then I need to know the exact rules for managing it.

H2ONaCl
  • 10,644
  • 14
  • 70
  • 114
  • http://stackoverflow.com/questions/285793/why-should-i-bother-about-serialversionuid – Perception Feb 19 '12 at 08:25
  • This link has a good discussion on this very subject. It also has links to some good resources on this matter. http://stackoverflow.com/questions/3284979/java-when-do-i-have-to-change-the-serialversionuid – H2ONaCl Feb 19 '12 at 13:40

4 Answers4

1

According to this answer - If I understand it correctly, you pretty much have to change the version ID if you break interface, like changing or removing signatures.

Change to a method logic can't introduce an incompatibility.

Community
  • 1
  • 1
Vic
  • 21,473
  • 11
  • 76
  • 97
  • 1
    I thought serialization only carries data so why would a method signature matter? – H2ONaCl Feb 19 '12 at 08:39
  • @broiyan - you've got a point, I'll edit it. Why did you ask about it in the original question then? :) – Vic Feb 19 '12 at 08:42
1

It's that the default notion of incompatible versions is typically too strict. If you add a field, it changes the default serialVersionUID which prevents you loading old data, even though that's probably a benign change. In fact, the stream contains a fullish description of the object's state, including the names and types of all its fields. This information is stored by the system, and it's generally enough for you to convert old data. The system also provides a default conversion (which skips unexpected fields and sets missing fields to their default values), which is often enough - but it's disabled if the serialVersionUID's don't match.

kornero
  • 1,109
  • 8
  • 11
  • Skipping unexpected fields and defaulting missing fields is great but I wonder if it is position dependent or identifier dependent? If identifier dependent then refactoring will break this helpful feature. – H2ONaCl Feb 19 '12 at 08:42
  • @broiyan It includes the field names in the type descriptor that it writes. Each serialized non-primitive non-String type is described once. The gory details: http://docs.oracle.com/javase/6/docs/platform/serialization/spec/protocol.html – Donal Fellows Feb 19 '12 at 08:57
  • 2
    The point of allowing the developer to use a specific serialversionuid is to remove any ambiguity about wether the JVM should attempt to read a stored class or not. Otherwise the runtime ***will*** attempt to load the class, and ***may*** fail if the class incompatibilities are too wide. The failure would be JVM implementation specific, but in general simply reordering of fields will ***not*** cause deserialization problems. – Perception Feb 19 '12 at 09:06
1

From Oracle, the list of compatible and incompatible changes. To address the question, bumping the ID is unnecessary ("invalid") if the change is compatible and "valid" if the change is incompatible.

H2ONaCl
  • 10,644
  • 14
  • 70
  • 114
0

Its similar to version-ing you do in version control systems. You published an initial class definition which is in use by some clients.

Now, later on you changed some of the class definitions. Using a different class version will make Your existing clients work without any problem.

Based on version Id the compatible clients can work without any issues !

Nrj
  • 6,723
  • 7
  • 46
  • 58