[7u-dev] Request for approval for JDK-7175464 - entrySetView field is never updated in NavigableSubMap

Martin Buchholz martinrb at google.com
Sun Feb 10 19:52:13 PST 2013


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.Bateman at oracle.com>wrote:

> On 09/02/2013 23:31, Martin Buchholz wrote:
>
>> On Sat, Feb 9, 2013 at 3:09 PM, Martin Buchholz<martinrb at 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
>
>
>
>



More information about the jdk7u-dev mailing list