Serialization opt-in syntax (summary)

[Brian Goetz]

I believe this option was on the list on the issue tracker?   

Sent from my iPhone

On Oct 12, 2012, at 5:31 PM, Sam Pullara <sam at sampullara.com> wrote:

> Crazy idea. Can we just make it a method call that wraps up the lamba in a wrapper that can be serialized? We could add the static method to Serializable:
> 
> Callable<Boolean> r = Serializable.wrap(() -> true);
> 
> It may have to be a little magical (not unlike serialization) but at least it is obvious and doesn't introduce anything new. You could even include the name if you want to make them more robust:
> 
> Callable<Boolean> r = Serializable.wrap("My True Callable", () -> true);
> 
> Sam
> 
> On Fri, Oct 12, 2012 at 9:06 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> I don't even agree that posterity would prefer it the other way, since there still are inner classes and many users have learned to deal with the frustrating interaction between inner classes and serialization.  A more accurate statement is that posterity would have preferred we not make the mistakes of the past the first time, but absent a time machine, we're kind of stuck there.  
> 
> In any case, I don't think "lambdas cannot be serializable" is a realistic option at this point.  Users will expect:
> 
>   SerializablePredicate p = x -> true
> 
> to be serializable -- and entirely reasonably so.  We made a commitment to SAM conversion a long time ago, and part of that is users should not have to reason about "how was this SAM constructed -- did it come from a lambda or a class?"  Otherwise it is a leaky abstraction.  Yes, serialization sucks -- and we're copying the suckage mode that users have spent 15 years getting used to.  But that 15 years of user community experience matters -- users have learned how to deal with the limitations, and there is a lot of value in not asking users to learn new and different limitations (especially those that punish the users who learned to live within the old limitations.)  
> 
> The EG took a poll on this at the July meeting last year, and was unanimously in favor of the "weak serialization" target.  David wasn't at that meeting, which is too bad, but I just don't see enough new evidence to reopen this issue now.  
> 
> However, we can and should spend our effort on "how can we make things as good as we can subject to the 'no worse than inner classes' rubric.  I suggest we redirect our efforts towards that.  Choosing a less-brittle translation strategy is a good place to start.  
> 
> On Oct 12, 2012, at 4:46 PM, Kevin Bourrillion wrote:
> 
>> On 10/12/2012 09:37 AM, Brian Goetz wrote:
>>  
>> I keep going back to the rubric of "no worse than inner classes."
>> 
>> On Fri, Oct 12, 2012 at 8:17 AM, David M. Lloyd <david.lloyd at redhat.com> wrote:
>> 
>> And I keep going back to "making the mistake once does not justify making it again"...
>> 
>> Ha. I completely see the sense in both of these mindsets.
>> 
>> Posterity hugely prefers that we see it the second way; yet here we are in the present tense and we have to get something working and deliver it. Is that the conflict we're having?
>> 
>> -- 
>> Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
>> 
> 
>