Serialization opt-in syntax (summary)

[Kevin Bourrillion]

Okay, this thread seems to have become about the stability issue again,
despite not having it in the subject line, so I'm going to move some
comments here that I made on another thread that didn't attract attention.

I don't think the first question on our minds should be how stable or not
stable serialization needs to be. I think the first question is: is it at
least possible to promise that serialization of an instance that was
created from a lambda expression will always either work correctly or
cleanly fail -- never give a bogus result?

If so, great; if not, the stakes are much higher here.



On Tue, Oct 9, 2012 at 8:00 AM, David M. Lloyd <david.lloyd at redhat.com>wrote:

> On 10/09/2012 09:33 AM, Remi Forax wrote:
>
>> On 10/09/2012 03:40 PM, David M. Lloyd wrote:
>>
>>> On 10/09/2012 01:07 AM, Remi Forax wrote:
>>>
>>>> We have several choices:
>>>>   - use an annotation like @Serial, but currently there is no way o
>>>> attach an annotation
>>>>      to an expression, so this was rule out.
>>>>   - use a cast to (Foo & Serializable) but the solution to allow users
>>>> to use & to specify a type
>>>>     is far from easy and require investigation and we haven't time for
>>>> that.
>>>>
>>>> so if no one has a better idea, this means we need a ad-hoc syntax to
>>>> specify that a lambda is serialize
>>>> (David, users want to serialize capturing lambda).
>>>>
>>>
>>> Users also want the compiler to magically do what they mean, not what
>>> they say... but in the end the best thing we can do for users is make
>>> the rules simple and predictable.
>>>
>>
>> I agree, but I think that if we have a way to tag lambda as
>> serializable, it's a simple and clear rule.
>>
>>
>>>  I think we have rule out to soon the fact that we also can use a
>>>> specific syntax, perhaps not x ~> x or
>>>> x -s> x (the snake arrow Josh had proposed) but a specific syntax is a
>>>> ad-hoc solution too.
>>>>
>>>
>>> I don't think you are grasping how incredibly unstable it will be to
>>> serialize a capturing lambda, and the fact that we are more concerned
>>> about what (we are assuming) users (think they) want versus what we
>>> know will be very fragile is very worrisome to me. I am certain that
>>> if we allow it as-is, it *will* impact the overall perception of
>>> stability of Java EE, which (like it or not) relies heavily upon
>>> serialization (including collections).
>>>
>>
>> serializing a lambda is as stable as serializing an anonymous class, so
>> you're right that because we don't offer a way
>> to have a stable name, collections implementations will not be able to
>> declare lambdas exactly like currently
>> there is no anonymous classes in the collection API, there are all
>> refactored as static inner classes to have a name.
>>
>> It seems that Kevin and Don, our API writers are Ok with that.
>>
>
> So you're saying "in order to be stable, lambdas must be refactored to
> have a name".  And you're saying "users can just do this refactoring if
> they want stability".  But I ask you, what is the rationale for allowing an
> unstable option in the first place?  If you know users have to refactor for
> stability, why give them the option to put a time-bomb in their code?  It's
> fine if API writers know better but users will *not*.
>
> It's pure cargo-cultism - we're just imitating something that doesn't work
> for the sake of being the same, which is silly wrong-headedness. If we
> can't do it right we simply shouldn't do it.
>
>
>  If we want to be able to support serializing capturing lambdas, they
>>> simply must have stable names, and their captured values must also
>>> have stable names; if we cannot do that then we simply cannot support it!
>>>
>>
>> No, a stable name + the SAM descriptor/implementation is enough because
>> the captured values are like values stored in fields,
>> so being Serializable is enough to serialize them.
>>
>
> Until they are reordered in a user's simple code refactor of their EJB,
> and then production code begins to fail in subtle ways.
>
> It's not enough to simply allow lambdas to be serializable.  We must also
> also ensure they are stable, otherwise we're making the world a worse place
> for no good reason.  "People want it" isn't enough justification to do
> something we know is wrong.  People want lots of things that we're not
> going to do.  What people really want is their code to be stable.  If
> superficial stability were enough, we'd all be running PHP, right?
>
> --
> - DML
>



-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20121009/1f47dbae/attachment.html