Is java object serialization compatible between 1.5 and 1.6

Question

I am wondering whether it is safe to mix jdk 1.5 and 1.6 (Java 6) object serialization (biderctional communication). I searched for an explicit statement from sun concerning

Answer 1

The serialization mechanism in 1.5 and 1.6 is compatible. Thus, the same code compiled/running in a 1.5 and 1.6 context can exchange serialized objects. Whether the two VM instances have the same/compatible version of the class (as may be indicated by the serialVersionUID field) is a different question not related to the JDK version.

If you have one serializable Foo.java and use this in a 1.5 and 1.6 JDK/VM, serialized instances of Foo created by one V; can be deserialized by the other.

Answer 2

Unless otherwise stated, this should be part of binary compatibility. Swing classes are explicitly not compatible between versions. If you find a problem with other classes, report a bug on bugs.sun.com.

Answer 3

Have you read the Java Object Serialization Specification? There is a topic on versioning. There is also an article for class implementers: Discover the secrets of the Java Serialization API. Each release of Java is accompanied by compatibility notes.

From the Java 6 spec on serialization:

---

The goals are to:

• Support bidirectional communication between different versions of a class operating in different virtual machines by:
  • Defining a mechanism that allows JavaTM classes to read streams written by older versions of the same class.
  • Defining a mechanism that allows JavaTM classes to write streams intended to be read by older versions of the same class.
• Provide default serialization for persistence and for RMI.
• Perform well and produce compact streams in simple cases, so that RMI can use serialization.
• Be able to identify and load classes that match the exact class used to write the stream.
• Keep the overhead low for nonversioned classes.
• Use a stream format that allows the traversal of the stream without having to invoke methods specific to the objects saved in the stream.

---

Answer 4

It is not safe to mix Java 1.5 and 1.6. For example, I have a Java 1.5 object serialized into a file and tried opening it in Java 1.6 but it came up with the error below.

java.io.InvalidClassException: javax.swing.JComponent; local class incompatible: stream classdesc serialVersionUID = 7917968344860800289, local class serialVersionUID = -1030230214076481435
    at java.io.ObjectStreamClass.initNonProxy(Unknown Source)
    at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source)
    at java.io.ObjectInputStream.readClassDesc(Unknown Source)
    at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source)
    at java.io.ObjectInputStream.readClassDesc(Unknown Source)
    at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source)
    at java.io.ObjectInputStream.readClassDesc(Unknown Source)
    at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
    at java.io.ObjectInputStream.readObject0(Unknown Source)
    at java.io.ObjectInputStream.readArray(Unknown Source)
    at java.io.ObjectInputStream.readObject0(Unknown Source)
    at java.io.ObjectInputStream.defaultReadFields(Unknown Source)
    at java.io.ObjectInputStream.readSerialData(Unknown Source)
    at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
    at java.io.ObjectInputStream.readObject0(Unknown Source)
    at java.io.ObjectInputStream.defaultReadFields(Unknown Source)
    at java.io.ObjectInputStream.readSerialData(Unknown Source)
    at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
    at java.io.ObjectInputStream.readObject0(Unknown Source)
    at java.io.ObjectInputStream.readArray(Unknown Source)
    at java.io.ObjectInputStream.readObject0(Unknown Source)
    at java.io.ObjectInputStream.defaultReadFields(Unknown Source)
    at java.io.ObjectInputStream.readSerialData(Unknown Source)
    at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
    at java.io.ObjectInputStream.readObject0(Unknown Source)
    at java.io.ObjectInputStream.readObject(Unknown Source)

Answer 5

The serialization mechanism itself has not changed. For individual classes it will depend on the specific class. If a class has a serialVersionUID field, this is supposed to indicate serialization compatiblity.

Something like:

private static final long serialVersionUID = 8683452581122892189L;

If it is unchanged, the serialized versions are compatible. For JDK classes this is guaranteed, but of course it is always possible to forget to update the serialVersionUID after making a breaking change.

When JDK classes are not guaranteed to be compatible, this is usually mentioned in the Javadoc.

Warning: Serialized objects of this class will not be compatible with future Swing releases

Answer 6

I would quickly add that it is possible to change the class but forget to change the serialVersionUID. So it is incorrect that "If the class defines a serialVersionUID, and this does not change, the class is guaranteed to be compatible." Rather, having the same serialVersionUID is the way an API promises backward compatibility.