Serialization stability (was: syntax)

[Kevin Bourrillion]

Two meta-questions:

* Can we ensure that in every case serialization will either work correctly
or fail outright?
* Can we ensure that it's very clear to users exactly when it will work and
when it won't?

If we do right by those, then I'm okay with just about any sacrifice we
have to make in the actual guarantee we make, all the way down to the bare
minimum "absolutely identical class files on both sides, only."


On Mon, Oct 8, 2012 at 8:45 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

>  Well, they don't really solve the problem of making serialization
>> correct; they accept as given that it's OK for anonymous and (worse yet)
>> capturing lambdas to be serialized with the expectation that it'll just
>> be flat-out wrong if you change the source in any way, which is
>> something I absolutely do not concede and which I firmly believe will
>> bite us (where "us"=="Java EE vendors"... and RMI users, and JPA users,
>> and just about any of the hundreds of widely-used serialization-based
>> technologies out there).
>>
>
> I think the correctness you seek is just inachievable.  Even with named
> classes, serialization has all sorts of limits and gotchas.  With inner
> classes, people have learned that you can use inner classes with
> serialization when you have identical bytecode on both sides of the pipe,
> and can't otherwise.  Its imperfect, but it seems a reasonable bar to say
> "no worse than inner classes".
>
> I get that you would like to set a higher bar -- and I'm open to seeing
> what we can do to meet a higher bar.  But first we should meet the bar we
> have, and we're stuck there.
>
>


-- 
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/20121008/48616f9a/attachment.html