On Oct 23, 2013, at 4:06 PM, Alan Bateman <[email protected]> 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.
>
Looks OK.
Testing wise if you really want to use lambda expressions then they need to be
explicitly marked as serializable otherwise it's gonna barf (as you probably
found out):
DoubleBinaryOperator plus = (DoubleBinaryOperator & Serializable) (x,
y) -> x + y;
Should you test accumulation/addition/reset after deserialization just to make
sure the value/identity are assigned correctly?
Paul.
