Serialization spec clarifications for lambda

[Brian Goetz]

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 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.