Re: [7u-dev] Request for approval for JDK-7175464 - entrySetView field is never updated in NavigableSubMap
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 long serialVersionUID = 7207038068494060240L;
static final ReverseComparator REVERSE_ORDER
= new ReverseComparator();
public int compare(ComparableObject c1, ComparableObject c2) {
return c2.compareTo(c1);
}
private Object readResolve() { return reverseOrder(); }
}
...the method readResolve() now calls default Comparator.reverseOrder(),
but previously it called the static Collections.reverseOrder()
Regards, Peter
On 02/10/2013 08:49 AM, Martin Buchholz wrote:
[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:
x=java.util.Collections$ReverseComparator@3710b205
y=java.util.Collections$ReverseComparator2@e9b8b810
x: 1 -1
y: -1 1
import java.util.*;
import java.io.*;
public class ReverseOrder {
public static void main(String[] args) throws Throwable {
Comparator x = Collections.reverseOrder();
Comparator y = serialClone(x);
System.out.printf(x=%s%n, x);
System.out.printf(y=%s%n, y);
System.out.printf(x: %d %d%n, x.compare(0,1), x.compare(1,0));
System.out.printf(y: %d %d%n, y.compare(0,1), y.compare(1,0));
}
static byte[] serialBytes(Object o) {
try {
ByteArrayOutputStream bos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(bos);
oos.writeObject(o);
oos.flush();
oos.close();
return bos.toByteArray();
} catch (Throwable t) {
throw new Error(t);
}
}
@SuppressWarnings(unchecked)
static T T serialClone(T o) {
try {
ObjectInputStream ois = new ObjectInputStream
(new ByteArrayInputStream(serialBytes(o)));
T clone = (T) ois.readObject();
return clone;
} catch (Throwable t) {
throw new Error(t);
}
}
}
On Sat, Feb 9, 2013 at 3:31 PM, Martin Buchholz marti...@google.com wrote:
On Sat, Feb 9, 2013 at 3:09 PM, Martin Buchholz marti...@google.comwrote:
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?
import java.util.*;
import java.io.*;
public class ReverseOrder {
public static void main(String[] args) throws Throwable {
Comparator c = Collections.reverseOrder();
if (c != serialClone(c))
throw new Error(String.format(c=%s clone=%s,
c, serialClone(c)));
}
static byte[] serialBytes(Object o) {
try {
ByteArrayOutputStream bos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(bos);
oos.writeObject(o);
oos.flush();
oos.close();
return bos.toByteArray();
} catch (Throwable t) {
throw new Error(t);
}
}
@SuppressWarnings(unchecked)
static T T serialClone(T o) {
try {
ObjectInputStream ois = new ObjectInputStream
(new ByteArrayInputStream(serialBytes(o)));
T clone = (T) ois.readObject();
return clone;
} catch (Throwable t) {
throw new Error(t);
}
}
}
On Fri, Feb 8, 2013 at 3:16 PM, Mike Duigou mike.dui...@oracle.comwrote:
Thank you for catching this Doug. I missed your original post on this
topic during my Christmas vacation. (
http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-December/013127.htmlfor
those following along at home)
I will definitely hold off and follow up on the potentially bad patch to
Java 8. I have created an issue to resolve the test breakage, JDK-8007889
Mike
On Feb 8 2013, at 11:43 , Doug Lea wrote:
On 02/08/13 14:33, Mike Duigou wrote:
Hello all;
I would like to backport this
Re: [7u-dev] Request for approval for JDK-7175464 - entrySetView field is never updated in NavigableSubMap
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 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
Re: [7u-dev] Request for approval for JDK-7175464 - entrySetView field is never updated in NavigableSubMap
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
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
Re: [7u-dev] Request for approval for JDK-7175464 - entrySetView field is never updated in NavigableSubMap
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 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 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
Re: [7u-dev] Request for approval for JDK-7175464 - entrySetView field is never updated in NavigableSubMap
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:
import java.util.*;
import java.io.*;
public class ReverseOrder {
public static void main(String[] args) throws Throwable {
Comparator c = Collections.reverseOrder();
if (c != serialClone(c))
throw new Error(String.format(c=%s clone=%s,
c, serialClone(c)));
}
static byte[] serialBytes(Object o) {
try {
ByteArrayOutputStream bos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(bos);
oos.writeObject(o);
oos.flush();
oos.close();
return bos.toByteArray();
} catch (Throwable t) {
throw new Error(t);
}
}
@SuppressWarnings(unchecked)
static T T serialClone(T o) {
try {
ObjectInputStream ois = new ObjectInputStream
(new ByteArrayInputStream(serialBytes(o)));
T clone = (T) ois.readObject();
return clone;
} catch (Throwable t) {
throw new Error(t);
}
}
}
On Fri, Feb 8, 2013 at 3:16 PM, Mike Duigou mike.dui...@oracle.com wrote:
Thank you for catching this Doug. I missed your original post on this
topic during my Christmas vacation. (
http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-December/013127.htmlfor
those following along at home)
I will definitely hold off and follow up on the potentially bad patch to
Java 8. I have created an issue to resolve the test breakage, JDK-8007889
Mike
On Feb 8 2013, at 11:43 , Doug Lea wrote:
On 02/08/13 14:33, Mike Duigou wrote:
Hello all;
I would like to backport this change from Java 8. It has been baking in
JDK8 for about two months with no problems.
I think it may have problems.
As I mentioned in a post a few months ago, it seems
to be responsible for breakage in a TCK/JCK test;
One derived from a jsr166 tck test at
http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/tck/TreeSubSetTest.java?view=log
You need the file for context, but it looks like:
public void testDescendingSerialization() throws Exception {
NavigableSet x = dset5();
NavigableSet y = serialClone(x);
assertTrue(x != y);
assertEquals(x.size(), y.size());
assertEquals(x.toString(), y.toString());
assertEquals(x, y);
assertEquals(y, x);
while (!x.isEmpty()) {
assertFalse(y.isEmpty());
assertEquals(x.pollFirst(), y.pollFirst());
}
assertTrue(y.isEmpty());
}
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7175464
http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/bf6ceb6b8f80
The change was previously reviewed by Alan Bateman, Paul Sandoz and
David Holmes before going in to Java 8.
Mike
Re: [7u-dev] Request for approval for JDK-7175464 - entrySetView field is never updated in NavigableSubMap
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?
import java.util.*;
import java.io.*;
public class ReverseOrder {
public static void main(String[] args) throws Throwable {
Comparator c = Collections.reverseOrder();
if (c != serialClone(c))
throw new Error(String.format(c=%s clone=%s,
c, serialClone(c)));
}
static byte[] serialBytes(Object o) {
try {
ByteArrayOutputStream bos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(bos);
oos.writeObject(o);
oos.flush();
oos.close();
return bos.toByteArray();
} catch (Throwable t) {
throw new Error(t);
}
}
@SuppressWarnings(unchecked)
static T T serialClone(T o) {
try {
ObjectInputStream ois = new ObjectInputStream
(new ByteArrayInputStream(serialBytes(o)));
T clone = (T) ois.readObject();
return clone;
} catch (Throwable t) {
throw new Error(t);
}
}
}
On Fri, Feb 8, 2013 at 3:16 PM, Mike Duigou mike.dui...@oracle.comwrote:
Thank you for catching this Doug. I missed your original post on this
topic during my Christmas vacation. (
http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-December/013127.htmlfor
those following along at home)
I will definitely hold off and follow up on the potentially bad patch to
Java 8. I have created an issue to resolve the test breakage, JDK-8007889
Mike
On Feb 8 2013, at 11:43 , Doug Lea wrote:
On 02/08/13 14:33, Mike Duigou wrote:
Hello all;
I would like to backport this change from Java 8. It has been baking
in JDK8 for about two months with no problems.
I think it may have problems.
As I mentioned in a post a few months ago, it seems
to be responsible for breakage in a TCK/JCK test;
One derived from a jsr166 tck test at
http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/tck/TreeSubSetTest.java?view=log
You need the file for context, but it looks like:
public void testDescendingSerialization() throws Exception {
NavigableSet x = dset5();
NavigableSet y = serialClone(x);
assertTrue(x != y);
assertEquals(x.size(), y.size());
assertEquals(x.toString(), y.toString());
assertEquals(x, y);
assertEquals(y, x);
while (!x.isEmpty()) {
assertFalse(y.isEmpty());
assertEquals(x.pollFirst(), y.pollFirst());
}
assertTrue(y.isEmpty());
}
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7175464
http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/bf6ceb6b8f80
The change was previously reviewed by Alan Bateman, Paul Sandoz and
David Holmes before going in to Java 8.
Mike
Re: [7u-dev] Request for approval for JDK-7175464 - entrySetView field is never updated in NavigableSubMap
[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:
x=java.util.Collections$ReverseComparator@3710b205
y=java.util.Collections$ReverseComparator2@e9b8b810
x: 1 -1
y: -1 1
import java.util.*;
import java.io.*;
public class ReverseOrder {
public static void main(String[] args) throws Throwable {
Comparator x = Collections.reverseOrder();
Comparator y = serialClone(x);
System.out.printf(x=%s%n, x);
System.out.printf(y=%s%n, y);
System.out.printf(x: %d %d%n, x.compare(0,1), x.compare(1,0));
System.out.printf(y: %d %d%n, y.compare(0,1), y.compare(1,0));
}
static byte[] serialBytes(Object o) {
try {
ByteArrayOutputStream bos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(bos);
oos.writeObject(o);
oos.flush();
oos.close();
return bos.toByteArray();
} catch (Throwable t) {
throw new Error(t);
}
}
@SuppressWarnings(unchecked)
static T T serialClone(T o) {
try {
ObjectInputStream ois = new ObjectInputStream
(new ByteArrayInputStream(serialBytes(o)));
T clone = (T) ois.readObject();
return clone;
} catch (Throwable t) {
throw new Error(t);
}
}
}
On Sat, Feb 9, 2013 at 3:31 PM, Martin Buchholz marti...@google.com wrote:
On Sat, Feb 9, 2013 at 3:09 PM, Martin Buchholz marti...@google.comwrote:
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?
import java.util.*;
import java.io.*;
public class ReverseOrder {
public static void main(String[] args) throws Throwable {
Comparator c = Collections.reverseOrder();
if (c != serialClone(c))
throw new Error(String.format(c=%s clone=%s,
c, serialClone(c)));
}
static byte[] serialBytes(Object o) {
try {
ByteArrayOutputStream bos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(bos);
oos.writeObject(o);
oos.flush();
oos.close();
return bos.toByteArray();
} catch (Throwable t) {
throw new Error(t);
}
}
@SuppressWarnings(unchecked)
static T T serialClone(T o) {
try {
ObjectInputStream ois = new ObjectInputStream
(new ByteArrayInputStream(serialBytes(o)));
T clone = (T) ois.readObject();
return clone;
} catch (Throwable t) {
throw new Error(t);
}
}
}
On Fri, Feb 8, 2013 at 3:16 PM, Mike Duigou mike.dui...@oracle.comwrote:
Thank you for catching this Doug. I missed your original post on this
topic during my Christmas vacation. (
http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-December/013127.htmlfor
those following along at home)
I will definitely hold off and follow up on the potentially bad patch to
Java 8. I have created an issue to resolve the test breakage, JDK-8007889
Mike
On Feb 8 2013, at 11:43 , Doug Lea wrote:
On 02/08/13 14:33, Mike Duigou wrote:
Hello all;
I would like to backport this change from Java 8. It has been baking
in JDK8 for about two months with no problems.
I think it may have problems.
As I mentioned in a post a few months ago, it seems
to be responsible for breakage in a TCK/JCK test;
One derived from a jsr166 tck test at
http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/tck/TreeSubSetTest.java?view=log
You need the file for context, but it looks like:
public void testDescendingSerialization() throws Exception {
NavigableSet x = dset5();
NavigableSet y = serialClone(x);
assertTrue(x != y);
assertEquals(x.size(), y.size());
assertEquals(x.toString(), y.toString());
assertEquals(x, y);
assertEquals(y, x);
while (!x.isEmpty()) {
assertFalse(y.isEmpty());
