Stability of lambda serialization
dl at cs.oswego.edu
Tue Aug 6 07:36:25 PDT 2013
On 08/06/13 09:17, David M. Lloyd wrote:
> 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".
I'm OK with 3rd alternative if some reasonably efficient
checksum/serial id ensuring breakage could be devised.
David, any ideas?
>> 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