Serialization opt-in syntax (summary)
kevinb at google.com
Fri Oct 12 07:11:19 PDT 2012
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
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.
>> 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
>> 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
More information about the lambda-spec-observers