Serialization opt-in syntax (summary)

Fri Oct 12 07:37:00 PDT 2012

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 univ-mlv.fr> 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 redhat.com <mailto: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 <mailto:kevinb at google.com>
> 
> 
> 
> 
> 
> -- 
> 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/20121012/ad31058d/attachment-0001.html 