Details
-
Bug
-
Resolution: Fixed
-
P5
-
8
-
b103
-
generic
-
generic
-
Verified
Description
Consider the file src/share/classes/sun/security/pkcs11/P11TlsPrfGenerator.java
It contains the following:
private static final SecretKey NULL_KEY = new SecretKey() {
private static final long serialVersionUID = -8090049519656411362L;
// ...
}
SecretKey is serializable, and the serialVersionUID was added to remove the warning
emitted by the compiler when a serializable class. However, the anonymous subclass
of SecretKey cannot make any guarantees about serialization compatibility, since it
has a compiler-generated, implementation-specific name that may vary uncontrollably
if the file is recompiled. (In JDK 7 it happens to be named P11TlsPrfGenerator$1.)
Since the point of serialVersionUID is to maintain serialization compatibility,
it's nonsensical for an anonymous class to define a serialVersionUID.
The serialVersionUID should be removed and an @SuppressWarnings annotation added.
Additionally, the compiler probably shouldn't issue a serialization warning in
these cases, but that's a separate issue.
For further information, see the note in section 1.10 of the Serialization specification,
http://docs.oracle.com/javase/7/docs/platform/serialization/spec/serial-arch.html#4539
It contains the following:
private static final SecretKey NULL_KEY = new SecretKey() {
private static final long serialVersionUID = -8090049519656411362L;
// ...
}
SecretKey is serializable, and the serialVersionUID was added to remove the warning
emitted by the compiler when a serializable class. However, the anonymous subclass
of SecretKey cannot make any guarantees about serialization compatibility, since it
has a compiler-generated, implementation-specific name that may vary uncontrollably
if the file is recompiled. (In JDK 7 it happens to be named P11TlsPrfGenerator$1.)
Since the point of serialVersionUID is to maintain serialization compatibility,
it's nonsensical for an anonymous class to define a serialVersionUID.
The serialVersionUID should be removed and an @SuppressWarnings annotation added.
Additionally, the compiler probably shouldn't issue a serialization warning in
these cases, but that's a separate issue.
For further information, see the note in section 1.10 of the Serialization specification,
http://docs.oracle.com/javase/7/docs/platform/serialization/spec/serial-arch.html#4539