-
Enhancement
-
Resolution: Unresolved
-
P3
-
None
-
5.0
-
None
-
generic
-
generic
The serialVersionUID of an interface that extends java.io.Serializable is actually significant: it DOES NOT matter when serializing an instance of the interface (in that case, only the serialVersionUID of the object's class and its serializable superclasses must match between the classes used to serialize the object and the classes used to deserialize the object), but it DOES matter when serializing the Class object for the interface: if the interface used to serialize the Class object had a different serialVersionUID than the interface resolved to deserialize it, the deserialization operation will fail with a java.io.InvalidClassException. This requirement that the serialVersionUIDs of interfaces match is problematic and should be waived, similar to how it is waived for array classes.
Little purpose is served by enforcing matching serialVersionUIDs for interfaces: the serialized form of their Class objects cannot evolve (in an interface-specific way), and they do not affect the serialized forms of their instances. One might argue that serialVersionUIDs could be used to detect incompatible evolution of an interface's contract, but only for interfaces that extend Serializable anyway (which are intentionally rare), and the merits of that means of enforcement are at best controversial.
Furthermore, the usual technique to keep serialVersionUIDs matching for evolved classes-- declaring an explicit serialVersionUID-- is highly problematic for interfaces, because interface members must be public; therefore, an interface's serialVersionUID is necessarily inherited as a public field by all subtypes in which it is not hidden. (See the Evaluation ofJDK-4228568 for more discussion about this problem.)
Fortunately, having an interface extend Serializable is discouraged as a matter of style, and interfaces are much less likely than classes to be evolved in ways that affect the fragile default serialVersionUID computation algorithm, so this issue hasn't been much of a practical problem so far (JDK-4228568 notwithstanding)-- but challenging cases could arise in the future, and it would seem prudent to standardize waiving the matching requirement before such cases arise.
Little purpose is served by enforcing matching serialVersionUIDs for interfaces: the serialized form of their Class objects cannot evolve (in an interface-specific way), and they do not affect the serialized forms of their instances. One might argue that serialVersionUIDs could be used to detect incompatible evolution of an interface's contract, but only for interfaces that extend Serializable anyway (which are intentionally rare), and the merits of that means of enforcement are at best controversial.
Furthermore, the usual technique to keep serialVersionUIDs matching for evolved classes-- declaring an explicit serialVersionUID-- is highly problematic for interfaces, because interface members must be public; therefore, an interface's serialVersionUID is necessarily inherited as a public field by all subtypes in which it is not hidden. (See the Evaluation of
Fortunately, having an interface extend Serializable is discouraged as a matter of style, and interfaces are much less likely than classes to be evolved in ways that affect the fragile default serialVersionUID computation algorithm, so this issue hasn't been much of a practical problem so far (
- relates to
-
JDK-4228568 Cricket Build "N" fails Signature Test...missing serialVersionUID fields in util
-
- Resolved
-
-
JDK-4503411 serialization spec should specify conditions under which SUID check is waived
-
- Resolved
-
-
JDK-6562388 Files compiled by make/java/java should be compiled with -Xlint:serial -Werror
-
- Closed
-
-
JDK-4490677 cannot deserialize array of class whose package access has changed
-
- Closed
-