On Oct 23, 2013, at 4:06 PM, Alan Bateman <alan.bate...@oracle.com> 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.