Serialization stability and naming (and syntax)

[Brian Goetz]

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

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.  

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.  

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