Strings in Switch

[Joshua Bloch]

Joe,

A few very minor clarifications:

On Mon, Dec 7, 2009 at 8:06 PM, Joe Darcy <Joe.Darcy at sun.com> wrote:

>
> Back in the dawn of time, the JLS also contained the javadoc of the
> platform classes.  JLSv1 had a hashing algorithm for string that that
> only sampled 8 or 9 characters of the string!  The actual javadoc had
> evolved to specify the current algorithm, which is a function of all the
> characters.  When the irresistible force the platform javadoc met the
> immovable object of the JLS, in this case the javadoc won


Actually the spec for the String hash function in JLS1e was subtly broken,
and unimplementable.  The implemented hash function (which the spec was
meant to describe) was awful.  I used the unimplementable spec as
justification for changing the spec and the implementation.  In chaos, there
is opportunity.

Such discrepancies and changes were long ago in a Java platform far, far
> away.  It is vanishingly unlikely that String.hashCode will change again
> in the SE platform because the "behavioral compatibility" impact would
> be too large; see
>
> "JDK Release Types and Compatibility Regions"
> http://blogs.sun.com/darcy/entry/release_types_compatibility_regions


I am in complete agreement here.


> As I understand it, some sophisticated collection implementations like
> ConcurrentHashMap already have internal re-hashing logic to cope with
> poor-quality hashCode implementations.
>

In fact, the lowly HashMap has had a secondary "defensive" hash function
ever since 1.4.

                   Josh