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

[Ulf Zibis]

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