Serialization opt-in syntax (summary)

Remi Forax forax at
Mon Oct 15 15:12:44 PDT 2012

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 ?


> On Oct 12, 2012, at 5:31 PM, Sam Pullara <sam at 
> <mailto:sam at>> 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 
>> <mailto:brian.goetz at>> 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 <mailto:david.lloyd at>> 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 <mailto:kevinb at>

More information about the lambda-spec-experts mailing list