Is the auto generated serialVersionUID always the same for all instances of the same class?

Question

The reason I ask this is because I am currently getting this error

java.io.InvalidClassException: com.my.package.TestObject; local class incompatible: stream classdesc serialVersionUID = 8401131515464509133, local class serialVersionUID = 581907934314849590

I get this because I am reading an old version of an object from a Redis cache but I have changed the object to have a new field - the old version of the class did not originally have a serialVersionUID so it's using this auto-generated one.

e.g old version

public static class TestObject implements Serializable {
        String id;
        String name;
    }

new version

public static class TestObject implements Serializable {
        String id;
        String name;
        String newField;
    }

Q - So my question is if I add private static final long serialVersionUID = 8401131515464509133L to the class will it be a problem for other instances of the object?

EDIT: the main question I am asking is does the value that was computed for the auto-generated serialVersionUuid each time a class is compiled? or can I rely on it been the same every compile? (when no new fields are added)?

I mean other older versions of the object instances of TestObject that are in the Redis Cache that will be deserialized — M_K, Jul 02 '19 at 15:16
This case above did not originally have the serialVersionUUID — M_K, Jul 02 '19 at 15:29
It's the same unless you changed something in the class that would change it, which is almost anything, and you did. This is all documented. — user207421, Jul 02 '19 at 21:57
OK thanks, so I can rely on the value 8401131515464509133 to be the same for all objects in my external Cache, add that serial uuid into my new class and thus a safe workaround — M_K, Jul 02 '19 at 22:04

Martin Strejc · Answer 1 · 2019-07-03T05:34:55.883

-1

Yes, for the same JRE you see the same default serialVersionUID for a class.

No, for different different versions of JRE.

In your case you can probably define explicit serialVersionUID that should help, but from your question that's not obvious, if all objects have been serialized by the same JRE. If not there is still a risk it won't help in all cases as explained below.

Once you change serialVersionUID of a class you can no longer deserialize older objects event though the rest of the class remain unchanged. Using default serialVersionUID is danger as well, because it gets calculated by JVM and there is no guarantee on consistency when you for example upgrade JRE version.

If you experience the issue with object serialization, you can try http://marjavamitjava.com/make-java-runtime-ignore-serialversionuids-deserializing/

But I'd prefer to use a different serializer than Java native binaries.

edited Jul 03 '19 at 05:34

answered Jul 02 '19 at 16:56

Martin Strejc

4,307
2
23
38

My problem here is I can't deserialize an older version of an object unless I explicitly add the serial version uuid from the exception above – M_K Jul 02 '19 at 17:57
@M_K So do that. – user207421 Jul 02 '19 at 21:56
@M_K default serialVersionUID is calculated in runtime, not in the compilation time. Thus you see a 'magic' number. You should always declared explicit serialVersionUID to prevent that issue. But you still cannot change any property even though serialVersionUID is the same. – Martin Strejc Jul 03 '19 at 05:01

Is the auto generated serialVersionUID always the same for all instances of the same class?

1 Answers1