JDK-4089540 : Fix Stream Protocol for Externalizable: Enable skipping externalizable data
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.io:serialization
  • Affected Version: 1.1.6,1.2.0
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_2.5
  • CPU: generic
  • Submitted: 1997-10-29
  • Updated: 1998-08-14
  • Resolved: 1998-08-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other Other
1.1.6 1.1.6Fixed 1.2.0Fixed
Related Reports
Relates :  
JDK-4088176 - backward compat. fails reading an evolved class with new field,nonexistant class
Description
Backwards compatibility of a serialized stream does not work for
following class evolution scenario.

A Serializable Class A is evolved in the following manner.

Add a new field, fieldA, to Class A.
The type of the field is also new and it is exernalizable.
Produce a serialized stream containing Class A.

Attempt to read the serialized stream using the original
Class A definition that did not include field A. Additionally,
the type of fieldA does not exist in this class path.

While reading an instance of A, the following stack trace is produced

java.io.StreamCorruptedException: Type code out of range, is 66
        at java.io.ObjectInputStream.peekCode(ObjectInputStream.java:1168)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236)
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.1.6 1.2beta3 FIXED IN: 1.1.6 1.2beta3 INTEGRATED IN: 1.1.6 1.2beta3 VERIFIED IN: 1.1.6
14-06-2004
WORK AROUND Make sure that the classes of all Externalizable classes written into a serialized stream are available when trying to read from the stream. Only the readExternal() method of the Externalizable class is able to know how to read the serialized data of an Externalizable class.
11-06-2004
SUGGESTED FIX This can not be fixed without adding protoocl to the current serialized stream protocol. Minimally, there has to be a way to SkipExternalData within the serialization subsystem when there is no local class equivalent of an Externalizable class. Given the current implementation, only the Externalizable class's readExternal() method can be used to skip external data within a serialized stream.
11-06-2004
PUBLIC COMMENTS Backwards compatibility of a serialized stream does not work for following class evolution scenario. A Serializable Class A is evolved in the following manner. Add a new field, fieldA, to Class A. The type of the field is also new and it is exernalizable. Produce a serialized stream containing Class A. Attempt to read the serialized stream using the original Class A definition that did not include field A. Additionally, the type of fieldA does not exist in this class path. While reading an instance of A, the following stack trace is produced java.io.StreamCorruptedException: Type code out of range, is 66 at java.io.ObjectInputStream.peekCode(ObjectInputStream.java:1168) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236)
10-06-2004
EVALUATION Requires approval from CCC. The only way to fix this is to make an incompatible change to the serialization stream. It is proposed to change the protocol to write externalizable data in blockdata mode and to terminate the output of writeExternal with TCENDBLOCKDATA tag. This change allows serialization to skip over externalizable data when the class does not exist in the local Virtual Machine. This change is incompatible because it means old externalizable classes can not be read by VM's with this change. However, no java core classes use externalizable so the impact of this change is not as bad as it could be. We really have no choice but to accept this incompatible change now, so Externalizable will work in future releases. joseph.fialli@East 1997-12-10 To enable forward compatibility, all new Externalizable data formats could be marked with a new flag SC_EXTERNALIZABLE_BLOCK_DATA_MODE added to the Externalizable classes class descriptor. Thus, JDK 1.2 would be able to check this bit and read either the old or the new Externalizable format. This would cut our losses as only not being able to read new Externalizable data into JDK 1.1.x JVM. joseph.fialli@East 1997-12-18
18-12-1997