Reputation: 7663
On a project, we have several objects serialized. It will be necessary to use these objects on machine with different JVM (possibly different versions).
Our objects serialVersionUID are fixed and won't change, but we are concerned about the serialVersionUID of the JVM standard objects, for instance ArrayList/HashSet that are used in our serialized objects.
So the question is, can these serialVersionUID change between different versions of JVM or between different JVM ?
Or do we have to use another serialization mechanism to support different JVMs ?
Upvotes: 4
Views: 982
Reputation: 7450
We use serialVersionUID
as a version code for the class, and we should change this field when we modify the class. This field is used as identity of the class in deserialization.
For example, you serialize a object of class A and save it in an binary file, you can deserialize file to the original object later. But if you add a field to A and do not change the serialVersionUID, the deserialization may return a malformed object. And if you change the serialVersionUID
, the deserialization will reject the input and throw an exception. An exception is better than a unknown error.
These error/exception happen if and only if you used an old serialization result to create a instance of a modified class. If you don't use serialization for data persistence, there won't be any problems.
Upvotes: -1
Reputation: 17878
The serialVersionUID should only be changed if there is a change to the class that would not be compatible with previously serialized versions of it.
To see what changes would potentially break compatibility check the Specification
I highly doubt that a new version of Java would introduce any changes to core classes that would break compatibility.
Upvotes: 3