Hi Alan,
That looks fine.
The signature of the readObject methods usually has the return type Object
even though in this case it should never be used. And a method comment
would be nice
saying why it always throws an exception.
I might have been tempted to conserve on classes and code duplication to
share a serialization proxy between the classes and maybe even shorten
the name.
But it is hard to argue with the simplicity and directness of this design.
The test is sufficient for a smoke test until the full serialization
tests are written/updated.
(Not a reviewer)
Roger
On 10/23/2013 10:06 AM, Alan Bateman wrote:
j.u.c.atomic.{Double,Long}.{Accumulator,Adder} extend a
package-private class Striped64 that does striping on 64-bit values.
This super type is Serializable by way of extending Number. Striped64
doesn't contribute any serial fields but its name does leak into the
serial stream because there is a descriptor for the super type when it
is also serializable. Those that write conformance tests have noticed
this.
In practical terms this is a bit of a non-issue but the reference to
Striped64 can be removed from the serial stream by changing these four
to use a serialization proxy. Doug has gone ahead and changed the
classes in jsr166 CVS and we need to bring these changes into jdk8/tl
by the ZBB date.
The webrev with the proposed changes is here:
http://cr.openjdk.java.net/~alanb/8026344/webrev/
A minor difference with what is currently in the CVS is that I've
added a link in the writeReplace javadoc to the proxy class. I've also
added a simple test as I didn't find any tests in the jdk repository
that exercise serialization of these classes.
-Alan.
