Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps (original) (raw)

Ulf Zibis Ulf.Zibis at gmx.de
Sat May 26 19:00:54 UTC 2012

Am 26.05.2012 20:15, schrieb Mike Duigou:

On May 26 2012, at 08:43 , Ulf Zibis wrote:

To where refers {@inheritDoc} ? To the new interface java.lang.Hashable32.hash32() Hm, but your String class in webrev 8/9 doesn't implement it.

I think, the javadoc should mention the term 'Murmur hash' and include a web link to the original author. Explicitly NO. This new hashing interface will not document it's algorithm so that unlike String.hashCode() we can change it in the future if we need to. I don't mean the interface, I mean the class. As HashMap doc describes it's internal structure in contrast to e.g. TreeMap, String.hash32() doc could mention it's internal implementation, and when to prefer it over hashCode(). If the inner algorithm becomes changed, the doc could be changed either.

And additionally IMO we should rename hash32() to something like murmurHash32(). No, for the previous reason. Here I'm with you.

But I still think, we should implement a more general approach according my last post. It seems to be overkill to me and of very limited value. New Map implementations could be created by third parties if this is useful to some users. The big problem for all later implementations would be, that they can't profit from an internal cache field in String, if it is not publicly accessible, as class String can't be subclassed, same for Java arrays. Additionally, if HashMap.hash() can't be overridden, one should duplicate the whole code of HashMap for an alternative implementation.

-Ulf

More information about the core-libs-dev mailing list