RFR : 7144488 StackOverflowError occurres on list via Collections.synchronizedList(List) (original) (raw)

Mike Duigou mike.duigou at oracle.com
Thu Feb 23 19:04:16 UTC 2012

The revised version looks good to me. It's worth getting all four.

On Feb 23 2012, at 06:46 , Seán Coffey wrote:

ok,

I've updated the changes (and bug synopsis) based on comments. equals method tweaked for : Collections.SynchronizedList Collections.SynchronizedSet Collections.SynchronizedMap Collections.UnmodifiableEntry Testcase updated also. JCK javautil tests run also. http://cr.openjdk.java.net/~coffeys/webrev.7144488.1/ regards, Sean. On 23/02/2012 09:56, David Holmes wrote: On 23/02/2012 7:55 PM, Alan Bateman wrote:

On 23/02/2012 02:44, David Holmes wrote:

All of the SynchronizedX.equals methods should be fixed ie SynchronizedSet, SynchronizedList and SynchronizedMap. It should always be valid to ask if a.equals(a). The idiomatic form used elsewhere (CheckedXXX) is: public boolean equals(Object o) { return o == this || list.equals(o); } I'm not a fan of collections containing themselves, but I think it is simple to fix contains(o)/contains[Key]|Value and remove(o) in a similar way. Though none of the wrapped collections currently handle that case, so I'm okay with not addressing this part. I don't see the recursion potential in hashCode() in the wrappers. The hashCode of a Set requires summing the hash codes of each of the elements so it can't work for the case that a set contains itself. Right, but that's a general problem with collections, not with the wrappers specifically. Cheers, David Anyway, I think the best we can do it to have the equals methods use the above form. I wasn't aware of the warning in List that Sean pointed out and maybe there should be similar warnings elsewhere. -Alan

More information about the core-libs-dev mailing list