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
>
>
>
>
