Question

What happens when I use an ObjectInputStream to read in a serialized object that is incompatible with the one currently defined in the program?
Do I get an exception or just totally mangled data?

Does it make any difference if I updated the serialVersionUID (as required) when compiling the newer version?

I have looked around and can’t seem to find what happens – only that you must update serialVersionUID.

Answer 1

This answer sums it up:

Imagine you have a class called Foo, and it has NO serialversionuid (the default), and you serialize an instance of Foo to a file. Later, you add some new members to the Foo class. If you try to deserialize the Foo object from the file, you will get a serialization failure stating that the objects are incompatible. They ARE incompatible, this is want you WANT and is the default. They are incompatible because new members in the Foo class cannot be initialized from the old serialized instance of Foo.

Now, you might say, "I don’t care, in my application it is acceptable for those fields to be uninitialized". If that REALLY is the case, you can set the serialversionuid of the NEW Foo class to be the same as the OLD Foo class. This will tell Java that the objects are compatible with respect to serializablity, and Java will not complain when you deserialize the old Foo instance into the new Foo class (but the new fields will still be uninitialized).

If you are creating a new class for the first time, and you set the serialversionuid, YOU ARE ENTERING A CONTRACT. You are saying, "For all future versions of this class with the same serialversionuid, I will guarantee they are compatible with respect to state and serialization".

If you change a class, and you EXPLICITLY want to DISALLOW deserialization of old versions, you can change the serialversionuid to a new value. This will cause an exception to be thrown if an old object is attempted to be deserialized into a new class instance.