Serialization opt-in syntax (summary)

[David M. Lloyd]

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