A HashMap bug with a Proxy value?

[Jing LV]

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