Stability of lambda serialization

[Doug Lea]

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
>> deserialization
>
> 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?

-Doug



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