Serialization opt-in syntax (summary)

Kevin Bourrillion kevinb at
Tue Oct 9 08:50:55 PDT 2012

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>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
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the lambda-spec-experts mailing list