Serialization opt-in syntax (summary)
David M. Lloyd
david.lloyd at redhat.com
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 univ-mlv.fr
>> <mailto: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.
>> On Tue, Oct 9, 2012 at 8:00 AM, David M. Lloyd
>> <david.lloyd at redhat.com <mailto:david.lloyd at redhat.com>
>> <mailto: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
>> 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
>> 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
>> 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"
>> 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
>> 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>
>> <mailto:kevinb at google.com <mailto:kevinb at google.com>>
>> Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com
>> <mailto:kevinb at google.com>
More information about the lambda-spec-observers