Understanding JDK Serialization Issues and the Importance of serialVersionUID

In a typical office chat, a developer (Yes) promises to add a new field to a class and release a version within minutes, while his teammate (Old Chen) is busy with a coffee break.

When the new field is added, the pre‑release test fails with a deserialization error, prompting an investigation into the Redis‑stored value.

It is discovered that the project uses JDK serialization and the class implements Serializable without explicitly defining a serialVersionUID . Consequently, the JVM generates a serialVersionUID based on the current class structure.

Reproduce

A simple Yes class with three fields is defined, instantiated, and the object is stored in Redis using JDK serialization. The stored value appears as garbled data, confirming JDK serialization.

After adding a new hobby field to the class and retrieving the previously stored value, deserialization fails because the computed serialVersionUID no longer matches the one used during serialization.

The error message explicitly states that the serialVersionUID in the stream differs from the local class’s serialVersionUID.

The root cause is that, without an explicit serialVersionUID, the JVM calculates it from the class’s current structure; any change (such as adding a field) changes the computed value, breaking compatibility.

To fix the problem, an explicit serialVersionUID is added to the class, the object is re‑cached, and then the new field is added. Deserialization succeeds, with the new field returning null as expected.

Conclusion

The story emphasizes that when using JDK serialization, you must always define a serialVersionUID to avoid version‑mismatch errors.

It also advises against using JDK serialization in production due to its performance and storage drawbacks, suggesting alternatives such as Hessian, JSON, or Protobuf for future comparisons.