Hi Martin,
It seems that adding a default method Comparator.reverseOrder() had an
impact on the code in Collections.
In he following code in Collections:
private static class ReverseComparator
implements ComparatorComparableObject, Serializable {
private static final
On 09/02/2013 23:31, Martin Buchholz wrote:
On Sat, Feb 9, 2013 at 3:09 PM, Martin Buchholzmarti...@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
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.comwrote:
On 09/02/2013 23:31, Martin Buchholz wrote:
On Sat, Feb 9, 2013 at 3:09 PM, Martin Buchholzmarti...@google.com
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
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
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
[adding lambda-dev]
Here's another refinement to the test case, which shows that a serial clone
of Collections.reverseOrder in lambda8 creates a new instance of a new
class with the opposite order (which I can't explain):
When run against latest lambda-b76, it gives this output:
