Serialization stability

[David M. Lloyd]

There is one thing I want to point out though - I think lambdas will be 
far more widely used than anon inner classes, especially given changes 
to the collections API specifically to make them more accessible.  So 
this, along with the capture semantics which make it impossible to use 
certain solutions available to anon/local classes (i.e. assign captured 
variables to explicitly named fields) makes them not strictly equivalent 
in my view.

I will continue to be strongly against allowing serializable anonymous 
lambdas, and even more strongly against allowing serializable capturing 
lambdas, unless someone comes up with a real mitigating solution to 
these problems.

On 10/08/2012 12:54 PM, Brian Goetz wrote:
> The point I am making is: if we adopt your "named only" rule, people
> absolutely *will* feel screwed over, and in a NEW and different way.
> Whereas if we go with the "no worse (and better if we can) than inner
> classes" bar, yes there will still be screwage, but it will be more of
> the same that they've been experiencing for years (and for which many
> people have learned to work around in one of many ways -- keep the bits
> constant, don't use anon classes -- all of which will still be valid.)
>
> I realize you deal with the users who are most affected by this.  I
> don't want to minimize this, since these are real problems experienced
> by real users, but let's also not lose sight of the fact that lots of
> people have figured out how to work around the pain of serialization
> with anonymous classes.
>
> I think our effort is best spent choosing the best translation scheme we
> can, and clearly identifying what the boundary of serializability is
> with respect to lambdas.
>
> On 10/8/2012 1:47 PM, David M. Lloyd wrote:
>> On 10/08/2012 12:26 PM, Brian Goetz wrote:
>>>> I disagree - anonymous classes were an oversight; just because one
>>>> thing
>>>> doesn't work does not give justification to make more problems.  It's
>>>> more of an excuse.  I think we *can* limit serialization to named
>>>> references, and this would cause a better user experience
>>>
>>> No, the user experience in this case would be terrible!  People would
>>> simply not understand why the "stupid compiler" is forcing you to
>>> manually desugar lambdas to method references, why static and unbound
>>> method refs are OK but not bound ones, or why simple lambdas like s ->
>>> true will not serialize, or why things that are expressible today as
>>> serializable anonymous classes don't work as lambdas.
>>>
>>> (I am not saying that your position is not one worth discussing, just
>>> that to call it a better user experience is kind of silly.)
>>
>> My experience with end users would pretty much uniformly give me the
>> opposite expectation ("if this was going to break why didn't it just say
>> so up front?").  If the compiler tells someone to do something, for the
>> most part they just do it (or do the couple keystrokes it takes for
>> their IDE to do it), and then remember for next time.  It's when things
>> start falling apart in production for non-obvious reasons that people
>> begin to feel like they've been screwed over.
>>


-- 
- DML