Stability of lambda serialization

[David M. Lloyd]

On 08/05/2013 06:49 PM, Dan Smith wrote:
>
> 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.

I do not think these problems are more serious.  In fact I had proposed 
multiple times to limit serializability to named method refs due to this 
potential issue.

> 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

Me: Reordering captured variables, reordering lambda incidence.  The 
EG's stance is just a generalization.  It's not a stance in any case: 
things which destabilize lambdas in terms of serializability are not a 
question of opinion, and it's bizarre to frame it that way.

> 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

I'm OK with either "you" or "third alternative".

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

I always advocate security over tolerance - to do otherwise invites CVEs 
(a possibly familiar story).  Capturing lambdas has been the focus of a 
couple recent emails of mine but indeed I do not think we should have 
any tolerance for any destabilizing of serialized lambdas.

I think that calculating a non-changeable serialVersionUID might be a 
good way forward, if we can work out what must enter in to the 
calculation (perhaps it's simply the entire compilation unit which 
includes the lambda).

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

I'd say breakage is the least concern.  But in any case I do not agree, 
and unless we can come to some solution, we will codify that 
disagreement in a No vote, since that's what it's for, after all.
-- 
- DML