Serialization opt-in syntax (summary)

David M. Lloyd david.lloyd at
Fri Oct 12 08:17:27 PDT 2012

And I keep going back to "making the mistake once does not justify 
making it again"...  it's better to just fail up front with 
NotSerializableException if the lambda is anonymous and/or capturing (of 
more than just the invocation target).

On 10/12/2012 09:37 AM, Brian Goetz wrote:
> I keep going back to the rubric of "no worse than inner classes."  In
> the case of an inner class that captures local integer variables x and
> y, if we reorder their references / declarations / rename them,
> serialized instances will have them backwards, but won't fail because
> the types will be right.  This maps exactly to a failure mode that would
> happen with the obvious implementation of lambda serialization.
> On Oct 12, 2012, at 3:11 PM, Kevin Bourrillion wrote:
>> On Tue, Oct 9, 2012 at 9:01 AM, Remi Forax <forax at
>> <mailto:forax at>> wrote:
>>     On 10/09/2012 05:50 PM, Kevin Bourrillion wrote:
>>         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.
>>     If you have two lambdas in a code, serialize the first one in a
>>     file, remove the code that contains that lambda,
>>     re-compile and deserialize, you can deserialize with the wrong lambda.
>> Can, and /should/, we act to prevent that? Calculate a hash based on
>> enough factors, include it in the serialized form and fail fast if the
>> hash doesn't match?
>>     Now, the serialization code check that the lambda are serialized
>>     and deserialized with the same SAM type,
>>     so the two lambdas must be converted using the same SAM, so this
>>     is equivalent to changing the code
>>     of a lambda between the time the lambda is serialized and the time
>>     the lambda is deserialized.
>>     I don't know if you consider that this is a bogus result or not,
>>     with classical serialization,
>>     you can change the code of a class with no trouble because the
>>     serial UID is calculated using the shape
>>     of the class not the bytecode instructions.
>>     Rémi
>>         On Tue, Oct 9, 2012 at 8:00 AM, David M. Lloyd
>>         <david.lloyd at <mailto:david.lloyd at>
>>         <mailto:david.lloyd at
>>         <mailto: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 <mailto:kevinb at>
>>         <mailto:kevinb at <mailto:kevinb at>>
>> --
>> Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at
>> <mailto:kevinb at>


More information about the lambda-spec-observers mailing list