Stability of lambda serialization

[Dan Smith]

On Sat, Aug 3, 2013 at 2:00 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> while *this particular* issue could be addressed, there is an infinite spectrum of similar issues that cannot be addressed, and that it is preferable to draw a clean line about what the user can expect in terms of code changes destabilizing lambdas.
> 
> That line is: If the code inside a method, or the method's signature, changes *in any way*, lambdas captured in that method should be considered destabilized.


On Aug 5, 2013, at 3:15 PM, David M. Lloyd <david.lloyd at redhat.com> wrote:

>  It's so much simpler to simply forbid serializing capturing lambdas, and much safer besides.

It's not clear to me why you feel that problems arising from captured variables are more serious than other problems that can arise from changes to the code inside a method.  For example, if I rearrange the order in which lambdas appear, old serialized (non-capturing) lambdas may match up with the wrong lambda on deserialization.

Also note that there are really two issues here: first, which changes are considered destabilizing, and second, what to do with destabilized lambdas.

What is destabilizing? EG: any change to a method; you: reordering captured variables

What to do? EG: make a best effort, with documented caveats; you: conservatively prohibit serialization of capturing lambdas; third alternative: conservatively detect problems and break at deserialization

If we have zero tolerance for destabilization of the serialized form, then we should either prohibit serialization of _all_ lambdas, or somehow encode the method contents (a hash?) and detect changes at deserialization time.  Prohibiting just capturing lambdas is a half measure.

The EG agreed instead to be tolerant, acknowledging that in the presence of a destabilizing change, sometimes everything works perfectly well, and occasionally things will break.

—Dan