Serialization opt-in syntax (summary)

[Remi Forax]

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.
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>
>