Stability of lambda serialization
David M. Lloyd
david.lloyd at redhat.com
Tue Aug 6 06:17:53 PDT 2013
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>
>> 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>
>> 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
> 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
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
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.
More information about the lambda-spec-observers