Serialization stability

[Brian Goetz]

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