CODEWITHSUNDEEP
javaserialization
Peter Kliem
Peter Kliem

Reputation:

Is java object serialization compatible between 1.5 and 1.6

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 this question but did not succeed. So, besides the technical feasability I am searching for an "official" statement concerning the problem.

Upvotes: 21

Views: 9417

Answers (8)

Tom Hawtin - tackline
Tom Hawtin - tackline

Reputation: 147154

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 in the Java Bug Database.

Upvotes: 2

Reputation:

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)

Upvotes: 0

oxbow_lakes
oxbow_lakes

Reputation: 134270

Note that the Java Beans specification details a version-independent serialization method which allows for strong backwards-compatibility. It also results in readable "serialized" forms. In fact a serialized object can be created pretty easily using the mechanism.

Look up the documentation to the XMLEncoder and XMLDecoder classes.

I wouldn't use this for passing an object over the wire necessarily (though if high performance is a requirement,I wouldn't use serialization either) but it's invaluable for persistent object storage.

Upvotes: 0

Tom
Tom

Reputation: 56332

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

Upvotes: 16

VoidPointer
VoidPointer

Reputation: 17831

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.

Upvotes: 3

McDowell
McDowell

Reputation: 108879

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.

Upvotes: 2

Alan
Alan

Reputation: 7064

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.

Upvotes: 2

GavinCattell
GavinCattell

Reputation: 3963

After testing with a serialized object written to a file using the ObjectOutputStream in a Java 1.5 program, then running a read with a ObjectInputStream in a Java 1.6 program I can say this worked without any issue.

Upvotes: 2

Related Questions