The following topics are covered:
ObjectStreamClassinstance for a non-serializable
Class, although doing so can be desirable when customizing the stream format for class descriptors (see 4413615 for more information). The new method ObjectStreamClass.lookupAny can now be used for this purpose.
ObjectInputStreamto be strongly referenced long after their use in a serialization operation, thus possibly delaying garbage collection of their defining class loaders indefinitely. Internal caches in the serialization implementation have been restructured to fix this bug.
Enum.valueOfmethod is called with that class and the received constant name in order to obtain the enum constant to return.
ClassNotFoundExceptionthrown by the
ObjectInputStream.readClassDescriptormethod would be reflected to the top-level caller of
StreamCorruptedExceptionwith an empty cause. It is now reflected to the top-level caller as an
InvalidClassExceptionwith the original
ClassNotFoundExceptionas the cause.
ObjectStreamClass.lookupmethod could deadlock if called from within the static initializer of the class represented by the method's
Classargument. Deadlock should no longer occur in this case.
Serializableinterface has been expanded to more completely specify the role and usage of
serialVersionUIDs, and to emphasize the need to specify explicit
serialVersionUIDs for serializable classes.
These APIs can be used to more efficiently read contained array objects in a secure fashion.
ObjectInputStream's public one-argument constructor requires the "enableSubclassImplementation" SerializablePermission when invoked (either directly or indirectly) by a subclass which overrides ObjectInputStream.readFields or ObjectInputStream.readUnshared.
These changes will not affect the great majority of applications. However, it will affect any ObjectInputStream/ObjectOutputStream subclasses which override the putFields or readFields methods without also overriding the rest of the serialization infrastructure.
private void readObjectNoData() throws ObjectStreamException;The readObjectNoData() method is analogous to the class-defined readObject() method, except that (if defined) it is called in cases where the class descriptor for a superclass of the object being deserialized (and hence the object data described by that class descriptor) is not present in the serialization stream. More formally: If object O of class C is being deserialized, and S is a superclass of C in the VM which is deserializing O, then S.readObjectNoData() is invoked by ObjectInputStream during the deserialization of O if and only if the following conditions are true:
See the class description in the API specification of ObjectInputStream for more information.
java.io.UTFDataFormatExceptionbeing thrown. In this release, the serialization protocol has been enhanced to allow strings longer than 64K to be serialized. Note that if a 1.2 (or earlier) JVM attempts to read a long string written from a 1.3-compatible JVM, the 1.2 (or earlier) JVM will receive a
java.lang.ClassNotFoundExceptionis thrown instead of a generic one so that more information about the failure is available. Also, deserialization exception reporting now includes maintaining the name of the original class that could not be found instead of reporting a higher-level class that was being deserialized. For example, if (in an RMI call) the stub class can be found but the remote interface class cannot, the serialization mechanism will now report correctly that the interface class was the class that could not be found instead of erroneously reporting that the stub class could not be found.
readClassDescriptormethods have been added to provide a means of customizing the serialized representation of
writeClassDescriptoris called when an instance of
java.io.ObjectStreamClassneeds to be serialized, and is responsible for writing the
ObjectStreamClassto the serialization stream. Conversely,
readClassDescriptoris called when the
ObjectStreamClassinstance as the next item in the serialization stream. By overriding these methods, subclasses of
ObjectInputStreamcan transmit class descriptors in an application-specific format. For more information, refer to sections 2.1 and 3.1 of the Java Object Serialization Specification.
ObjectInputStream.resolveClass, except that they apply to dynamic proxy classes (see
java.lang.reflect.Proxy), as opposed to non-proxy classes. Subclasses of
annotateProxyClassto store custom data in the stream along with descriptors for dynamic proxy classes.
ObjectInputStreamsubclasses may then override
resolveProxyClassto make use of the custom data in selecting a local class to associate with the given proxy class descriptor. For details, see section 4 of the Java Object Serialization Specification.
@serialDatahave been added to provide a way to document the serialized form of a class. Javadoc generates a serialization specification based on the contents of these tags. For details, refer to section 1.6 of the Java Object Serialization Specification.
java.io.Externalizableinterface if the classes for those objects were not available. In this release, a new protocol version was added which addressed this deficiency. For backwards compatibility,
ObjectInputStreamcan read and write serialization streams written in either protocol; the protocol version used can be selected by calling the
ObjectOutputStream.useProtocolVersionmethod. For details and a discussion of compatibility issues, see section 6.3 of the Java Object Serialization Specification.
readResolvemethods which allow instances of the given classes to nominate replacements for themselves during serialization and deserialization. The required signatures of these methods, along with further details, are described in sections 2.5 and 3.6 of the Java Object Serialization Specification.
ObjectInputStreamcan implement a custom serialization protocol by overriding the
readObjectOverridemethods. Note that these methods will only be called if the
ObjectOutputStream/ObjectInputStreamsubclasses possess the permission
java.io.SerializablePermission("enableSubclassImplementation"), and call the no-argument constructors of
ObjectOutputStream/ObjectInputStream. See sections 2.1 and 3.1 of the Java Object Serialization Specification for more information.
ObjectInputStreammay override inherited methods to obtain "hooks" into certain aspects of the serialization process. Since this release, object serialization uses the 1.2 security model to verify that subclasses possess adequate permissions to override certain hooks. The permissions
java.io.SerializablePermission("enableSubstitution") govern whether or not the methods
ObjectInputStream.resolveObjectwill be called during the course of serialization. See sections 2.1 and 3.1 of the Java Object Serialization Specifications for more information.
serialPersistentFields, serializable classes can dictate which fields will be written when instances of the class (or subclasses) are serialized. This feature also enables classes to "define" serializable fields which do not correspond directly to actual fields in the class. Used in conjunction with the serializable fields API (described below), this capability allows fields to be added or removed from a class without altering the serialized representation of the class. See sections 1.5 and 1.7 of the Java Object Serialization Specification for details.
readObjectmethods to explicitly set and retrieve serializable field values by name and type. This API is particularly useful for classes that need to maintain backwards compatibility with older class versions; in some cases, the older version of the class may have defined a set of serializable fields that cannot be mapped directly to the fields of the current class. In this case, newer versions of the class can define custom
readObjectmethods that convert the internal state of a given instance of the (new) class into the "old" serialized form, and vice versa. For more information, see section 1.7 of the Java Object Serialization Specification.