Serialization opt-in syntax (summary)

[Kevin Bourrillion]

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/be543d59/attachment-0001.html