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
