A HashMap bug with a Proxy value? (original) (raw)

Jing LV lvjing at linux.vnet.ibm.com
Thu Jan 13 06:06:20 UTC 2011

Hi,

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 that. I believe David's experience 2

  1. 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.

Any idea?

于 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. -Chris I assume he is talking about java.lang.reflect.Proxy as it forwards the hashCode and equals methods to the invocation handler. -Alan

More information about the core-libs-dev mailing list