A HashMap bug with a Proxy value?
lvjing at linux.vnet.ibm.com
Thu Jan 13 06:06:20 UTC 2011
Chris, David and Alan, thanks for comments. Yes I was talking about the
java.lang.reflect.Proxy, and proxy.equals(proxy) will return false if
equals() (in InvocationHandler) is not well overriden. There is some
solution on this problem (on spec. etc. ). However but for common
developers (e.g J2EE developer may use Proxy usually) may not care about
I believe David's experience 2
2. Any object class for which, when given two instances "a" and "b", a
== b is true but a.equals(b) is false is incorrectly implementing .equals().
is true. I wonder the design for Proxy and InvocationHandler can be
enhanced by creating a default equals/toString/hashCode implementation
for Proxy correctly, not ask developers to do it again and again
whenever he uses Proxy. Anyway, this may be another story.
I think for HashMap, it may be benefit to check "==" as well as equals
in containsValue() (as containsKey already do) which is a quick solution
to resolve such problems.
于 2011-1-13 0:59, Alan Bateman 写道:
> Chris Hegarty wrote:
>> Are you referring to java.net.Proxy? Proxy.equals depends on the
>> resolution of its address. Address resolution could change over time,
>> depending on the caching policy. java.net.URL has a similar issue.
>> Strangely,I would have expected containsValue and containsKey to behave
>> in a similar fashion. I think the specification for these methods is
>> very clear, they should use equals(). I'm not sure if containsKey is
>> correct if it accepts key equality.
> I assume he is talking about java.lang.reflect.Proxy as it forwards
> the hashCode and equals methods to the invocation handler.
More information about the core-libs-dev