Serialization stability and naming (and syntax)

[David M. Lloyd]

On 10/01/2012 09:02 AM, Brian Goetz wrote:
>>> Why not consider limiting serializability to lambdas built from method
>>> references?
>>
>> Yes! I can't think of any reason not to do this.
>
> Its a good complexity-reducing idea, but I think its impractical.
>
> Users will expect, reasonably, for this to work:
>
> interface SerializablePredicate extends Predicate, Serializable { }
>
> SerializablePredicate p = e -> true;
>
> // serialize p
>
> Failing to have p be serializable here would definitely violate the principle of least surprise.  So we cannot draw the line at "method refs OK, lambdas not".

There is precedent for this kind of potentially surprising behavior. 
The java.lang.reflect.Proxy base class is Serializable, though not all 
proxies are indeed actually serializable.  Non-capturing lambdas are 
really very proxy-like; I think it's perfectly reasonable for all lambda 
implementation classes to be serializable and defer that check to, say, 
the MethodHandle.

I don't think the principle of least surprise is a good first principle. 
I think first must come "works correctly/predictably/consistently or 
doesn't work at all".  I realize there will be surprises; this is 
unavoidable.  I'd rather the surprise be "oh, I guess need to move this 
to a method" in response to a very clear error/warning during build or 
testing than even one "oh, my app worked in production for years and 
broke after this upgrade and I have absolutely no idea why".

> Similarly, trying to draw the line at "non capturing lambdas OK, capturing not" is similarly problematic; users won't even realize when they're capturing something.

I agree this is a problem.  It would be nice if we could simply not have 
capturing lambdas at all, but I will never win that battle, even though 
implementation-wise it still seems hard to see a clear benefit of a 
capturing lambda over an inner class.

> But, as long as we're satisfied with the serialization stability requirements that we discussed at the outset -- that it works as long as the bytecode is the same on both sides, and we're not trying to make heroic efforts beyond that, I think we're fine.

I do not find this answer satisfactory; I think we will cases 
(especially in Java EE applications) where application upgrades will 
cause bizarre regressions that even experienced developers will miss 
because of this, even more so than inner classes due to the fact that we 
and others will no doubt be strongly pushing people to use these things 
in their code much more than anyone ever promoted inner classes.

> And I think we've mostly concluded that the primary motivator for having a name for a lambda is not serialization, but toString.

That's valid from the POV of a lambda implementer but I don't think 
typical application developers, who rely on serialization heavily 
whether we like it or not, will find that to be a great comfort in that 
logic.

-- 
- DML