StackOverflowError on HashMap.hashCode() due to self reference
fweimer at redhat.com
Mon Jul 20 12:07:04 UTC 2015
On 07/17/2015 09:25 PM, Louis Wasserman wrote:
> The Javadoc of Map already specifies:
>> > Note: great care must be exercised if mutable objects are used as map
> keys. The behavior of a map is not specified if the value of an object is
> changed in a manner that affects equals comparisons while the object is a
> key in the map. *A special case of this prohibition is that it is not
> permissible for a map to contain itself as a key. While it is permissible
> for a map to contain itself as a value, extreme caution is advised:
> the **equals and hashCode methods
> are no longer well defined on such a map.*
The problematic entry had the self-reference in the value, not the key,
so this explanation does not really apply here.
But java.util.Collections does mention this problem:
Some collection operations which perform recursive traversal of the
collection may fail with an exception for self-referential instances
where the collection directly or indirectly contains itself. This
includes the clone(), equals(), hashCode() and toString() methods.
Implementations may optionally handle the self-referential scenario,
however most current implementations do not do so.
Florian Weimer / Red Hat Product Security
More information about the core-libs-dev