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

David Holmes david.holmes at oracle.com
Thu Feb 23 21:31:49 UTC 2012

On 23/02/2012 10:41 PM, Doug Lea wrote:
> On 02/22/12 21:44, David Holmes wrote:
>> I'm not a fan of collections containing themselves, but I think it is
>> simple to fix contains(o)/contains[Key]|[Value](o) 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.
> It was a deliberate decision not to include any evasive schemes
> for collections that contain themselves, because the problem is
> unsolvable in general. The patch addresses those that directly contain
> themselves, but not the transitive closure, as in:
> c1 contains c2 that in turn contains c1. Our take was that
> it is a feature, not a bug, that anyone using equals or hashCode
> in such cases hits infinite recursion.

I must confess that I had misunderstood the basic issue here and thought 
that there was a problem independent of self-containment.

That said, an equals method that checks for o==this is pretty normal 
(and recommended by Effective Java Item 7) and we at least now have 
consistency amongst the wrapper classes. I'll add a note to the CR to 
that effect.

Michael: good to go (if it hasn't already)


> People are free to change policies about this, but do bear in
> mind that any changes along these lines are intrinsically
> incomplete.
> (Although for pre-collections (Java1.1) legacy
> compatibility reasons, java.util.Hashtable.hashCode does
> include an ugly stopgap to avoid infinite recursion
> in the direct case.)
> -Doug

More information about the core-libs-dev mailing list