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.

Reply via email to