On 24/05/2012 2:24 AM, Mike Duigou wrote:
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.
Is it worth using:
&& (k instanceof String || k instanceof Hash32)
to deal with that. What would be the penalty on non-String Hash32's?
David
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
