Serialization opt-in syntax (summary)
forax at univ-mlv.fr
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
> 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);
>> 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
>> 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
>>> 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>
More information about the lambda-spec-observers