Shouldn't HashSet/Map use Arrays.hashCode(x[]) ?

[Ulf Zibis]

Am 04.06.2010 20:26, schrieb Martin Buchholz:
> Aside from the fact that it would be a hugely incompatible change
> to change the hashing/equality algorithm now,
> it is quite a religious argument about which is the Right Thing to do.
>    

In most cases we have freedom of religion as we have HashMap and 
IdentityHashMap.
There is one exception (maybe more?) for x[] as key.
Both compare arrays on identity level, and unfortunately it's almost 
impossible to change this due to incompatibility.
Bug ID 6812862 would provide this religion freedom as a side effect. So 
I again don't understand the resistance against it.

> Here's some religion/philosophy for you:
> http://home.pipeline.com/~hbaker1/ObjectIdentity.html
>    

Thanks for this interesting historical pre-Java paper.

-Ulf


> There are some existing collections, e.g. BlockingQueues,
> that use identity comparison instead of content comparison.
>
> Martin
>
> On Fri, Jun 4, 2010 at 08:49, Ulf Zibis<Ulf.Zibis at gmx.de>  wrote:
>    
>> Otherwise e.g. int[] as key for HashSet/Map doesn't make any sense.
>>
>> I use a class where the content of an int[] defines the uniqueness or there
>> instances.
>> Before I create a new instance, I have to check if there is just one for the
>> same int[] content.
>> Using the current HashSet/Map implementation does not serve this need.
>> It seems, that I should first instantiate a temporary object containing the
>> int[], hash it in the set/map, and later throw it away. :-(
>>
>> Maybe another reason for solving
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6812862
>>
>> -Ulf
>>
>>
>>
>>      
>
>