A HashMap bug with a Proxy value?
lvjing at linux.vnet.ibm.com
Thu Feb 17 08:24:23 UTC 2011
Hello, is there any other comments on this issue? Can someone help raise
a bug on Sun's bug system? Thanks.
? 2011-1-19 17:06, Jing LV ??:
> 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
>> > to resolve such problems.
>> Seems like the identity check would be a win:
Jimmy, Jing LV
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the core-libs-dev