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