A HashMap bug with a Proxy value?
lvjing at linux.vnet.ibm.com
Wed Jan 19 09:06:09 UTC 2011
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
> > I think for HashMap, it may be benefit to check "==" as well as equals
> > in containsValue() (as containsKey already do) which is a quick
> > to resolve such problems.
> Seems like the identity check would be a win:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the core-libs-dev