简体   繁体   中英

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.

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

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.

在使用Java 1.5程序中的ObjectOutputStream将序列化对象写入文件进行测试之后,然后在Java 1.6程序中运行带有ObjectInputStream的读取,我可以说这没有任何问题。

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.

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 .

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.

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.

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)

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM