Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps

[Mike Duigou]

Hi Mike;

The problem with using instanceof Hashable32 is that is much slower (often more than 25X) than instanceof String. It's slow enough that we won't reasonably consider using instanceof Hashable32 in JDK 8. We have considered making Object implement Hashable32 and add a virtual extension method to Object for hash32(). The extension method would just call hashCode(). A compiler that supports extension methods is not yet part of the JDK mainline repo yet (It is still in the Lambda repo). This approach would mean that we can avoid an instanceof check but there is a *lot* of entirely reasonable reservations about having Object implement an interface and gain a new method.

Opinions and insights welcome,

Mike

On May 23 2012, at 00:38 , Mike Skells wrote:

> Hi Mike,
> 
> I have a query, why is this implementation limitted to String?
> Is this by intent?
> 
> in HashMap the patch for hash calculation is 
>  290     final int hash(Object k) {
>  291         int h = hashMask;
>  292         if ((0 != h) && (k instanceof String)) {
>  293             return h ^ ((String)k).hash32();
> ....
> whereas I would have thought that it should be 
>  290     final int hash(Object k) {
>  291         int h = hashMask;
>  292         if ((0 != h) && (k instanceof Hash32)) {
>  293             return h ^ ((Hash32)k).hash32();
> ....
> 
> As a more flexible improvement could you supply a HashCode and Equals delegate, and then the user can supply either a custom delegate, suitable for that application (e.g.one that iterates through array content, or any other application data structure that needs to be handled differently like c# uses http://msdn.microsoft.com/en-us/library/system.collections.iequalitycomparer )
> 
> Regards
> 
> Mike