A HashMap bug with a Proxy value?

[Jing LV]

Hi,

        Thanks for information. I've raised a new bug on openjdk bug 
system (https://bugs.openjdk.java.net/show_bug.cgi?id=100165) with 
testcase and patch.

? 2011-1-14 1:46, Jason Mehrens ??:
>
> > 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.
>
> See: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4652876
>
> The ProxyGenerator could safely add byte codes to 
> equals/compareTo/compare that:
> 1. Handle the null case per contract: false, NPE, call handler.
> 2. Proxy == Argument: true, 0, 0
> 3. Proxy.getClass() == Argument.getClass() && Proxy.h == 
> Proxy.getClass().cast(argument).h: true,0,0
>
> The problem is short circuit operations nor return value overrides are 
> not allowed per the Proxy contract: "A method invocation on a proxy 
> instance through one of its proxy interfaces will be dispatched to the 
> invoke method of the instance's invocation handler...the result that 
> it returns will be returned as the result of the method invocation on 
> the proxy instance."
>
> I think for most equality checks, short circuit would be for the 
> most part safe since most Collections all ready do such checks but, it 
> requires a change to the Proxy contract which presents a compatibility 
> problem.
>
>
> > 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.
>
> Seems like the identity check would be a win: 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6486197
>
> Jason
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20110119/0c74a52d/attachment.html>