Thank you Doug, Martin, Peter and Alan for efforts your in tracking this down.
Even though it's not implicated, I am going to hold off on the OpenJDK7u-dev
push of 7175464 for a few days to allow for some additional testing.
Mike
On Feb 10 2013, at 19:52 , Martin Buchholz wrote:
> Alright, now that the problem (if not the solution) is well understood, I
> leave it to you.
>
> Martin
>
> On Sun, Feb 10, 2013 at 2:54 AM, Alan Bateman <alan.bate...@oracle.com> wrote:
> On 09/02/2013 23:31, Martin Buchholz wrote:
> On Sat, Feb 9, 2013 at 3:09 PM, Martin Buchholz<marti...@google.com> wrote:
>
> It looks to me like Collections.reverseOrder no longer deserializes to the
> same object. It also looks like the definition for that in
> Collections.java hasn't changed recently. So I suspect that there has been
> some serious incompatible change to deserialization itself.
> (It's another matter whether that could break TreeSet).
> (I have long lobbied for more cross-jdk testing focused on seriallization)
>
> The program below demonstrates the different behavior between jdk7 and
> jdk8:
>
>
> Oops - correction - this is not a difference between jdk7 and jdk8, but
> between jdk8 and lambda8, More specifically, lambda-8-b74 fails,
> while jdk8-b74 succeeds. Have lambdadukes messed with serialization?
>
> Collections.ReverseComparator's readResolve is:
>
>
> private Object readResolve() { return reverseOrder(); }
>
> so I assume it's the new Comparator.reverseOrder() that is used now rather
> than Collections.reverseOrder() as before. Ha, this means it's returning a
> compator to reverse itself.
>
> This one aside, this is another issue with serialization that has come about
> because of default methods and because declared methods are used in the
> computation of the default serial version UID. Mike and Stuart are looking
> into that one (I think it came up on the lambda-dev list recently).
>
> -Alan
>
>
>
>
