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
