Stability of lambda serialization

[Paul Benedict]

My armchair opinion says lambdas shouldn't suffer from the same level of
serialization issues because, as they were originally and still are today,
touted as the better replacement to today's status quo: "In this respect,
anonymous inner classes are imperfect for a number of reasons... This
project addresses many of these issues." [1].

True, it is a compiler decision to whether the lambda translation becomes a
static method or inner class, but these details shouldn't be leaked to the
developer. The "leaky abstraction" here is the serialization. Lambdas help
to escape anonymous inner classes at the language level, but their legacy
is still being dragged along under the hood. What's the point if I can't
overcome the latter?

I won't be using lambdas in any EE application if the EG keeps its
decision. EE developers have it down to an art when the calculated
serialization value will change. This is really important for patching
middleware. Generally speaking, I know the value is affected by method
signatures and fields. Patches can be done on the server-side alone as long
as those go untouched --- and I don't want to my method bodies now to
compound the problem (!!!). David's parameter swapping example looks pretty
severe to me. The best solution for my teams, at this point, is not to use
lambdas in any object that can be serialized.

PS: I am no fan at all at the "things are broken here so it's okay if they
are equally broken there" philosophy. I know that's not anyone's exact
words but that's how I synthesized the explanation, and it's not the first
time that explanation has been expressed here. If time constraints are
underlying driving that, okay, but if not, I prefer something better be
done.

[1] http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-4.html

Cheers,
Paul


On Tue, Aug 6, 2013 at 8:17 AM, David M. Lloyd <david.lloyd at redhat.com>wrote:

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



-- 
Cheers,
Paul