Serialization opt-in syntax (summary)
spullara at gmail.com
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 oracle.com> 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 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
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 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
> 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>
> 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
More information about the lambda-spec-observers