Serialization opt-in syntax (summary)

[Remi Forax]

On 10/12/2012 08:17 PM, Brian Goetz wrote:
> I believe this option was on the list on the issue tracker?
>
> Sent from my iPhone

How do you want to implement that ?
Patch the compiler and the spec to emit an invokedynamic when wrap() is 
called ?

Rémi

>
> On Oct 12, 2012, at 5:31 PM, Sam Pullara <sam at sampullara.com 
> <mailto: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 
>> <mailto: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 <mailto: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 <mailto:kevinb at google.com>
>>>
>>
>>