Serialization opt-in syntax (summary)

Sam Pullara spullara at
Fri Oct 12 12:13:10 PDT 2012

Must have missed it. I think I would prefer something like this. Will
update my comment.


All my photos are panoramas.

On Oct 12, 2012, at 11:17 AM, Brian Goetz <brian.goetz at> wrote:

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

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);


On Fri, Oct 12, 2012 at 9:06 AM, Brian Goetz <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>
>  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
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the lambda-spec-experts mailing list