Serialization spec clarifications for lambda

[Paul Sandoz]

On Oct 21, 2013, at 7:27 PM, Brian Goetz <brian.goetz at Oracle.COM> wrote:

> The serialization spec currently has some language about how inner classes are risky to serialize -- see the Note at the bottom of section 1.10 here: http://docs.oracle.com/javase/7/docs/platform/serialization/spec/serial-arch.html#4539
> 
> I propose to add the following additional note regarding the serialization risks of lambdas.  Comments welcome (though note Public Review starts next week, so not much time to dither.)
> 
> Note - As with inner classes, serialization of lambda expressions is strongly discouraged.  Names of synthetic methods generated by javac (or other Java(TM) compilers) to implement lambda expressions are implementation-dependent, may vary between compilers, and may change due to unrelated modifications in the same source file; differences in such names can disrupt compatibility.  Lambda expressions may refer to values from the enclosing scope; when the lambda expressions serialized, these values will be serialized as well.  The order in which values

Typo: when the lambda expressions *are* serialized. 

Might read better if "lambda expressions" is re-written in the singular? as is the case in the next sentence.

Paul.

> from the enclosing scope are captured is implementation-dependent, may vary between compilers, and any modification of the source file containing the lambda expression may change this capture order, affecting deserialization correctness.  Lambda expressions cannot use field- or method-based mechanisms to control their serialized form.  If serializable lambdas are used, to minimize compatibility risks, it is recommended that identical classfiles as were present at serialization time be present at deserialization time.