Strings in Switch

[Reinier Zwitserloot]

String.hashCode()'s exact algorithm is codified in the official javadoc. It
is therefore canon. Thus, changing String.hashCode breaks backwards
compatibility. Java has never broken backwards compatibility in such a core
feature. Hell freezes over before hashCode() will change comes to mind.

If Strings are ever going to get a different hashCode algorithm, I expect it
will be an internal affair, with special-casing code in e.g. HashMap to use
the more efficient one, leaving the public-facing hashCode() intact, lest
tons of existing code that relies on string hashCodes breaks.

I'm not for or against any particular implementation of strings-in-switch,
just making an observation.

--Reinier Zwitserloot

Need to receive donations via the web?
Check https://tipit.to/



On Tue, Dec 8, 2009 at 3:00 AM, Paul Benedict <pbenedict at apache.org> wrote:

> Joe,
>
> On Mon, Dec 7, 2009 at 6:38 PM, Joseph D. Darcy <Joe.Darcy at sun.com> wrote:
> > we are aware of the potential problem and are making a different judgment
> on
> > the comfortability of the implementation strategy.
>
> Have you thought about calculating the hash code, not as part of the
> compiler's emitted bytecode, but when the class is loaded? Maybe it is
> possible to desugar the code into a static { } so the compiler's
> environment is taken out of the equation. However, this would mean
> your double-switch would no longer be usable since case labels must be
> constants, but there are no constant restrictions regarding if/else
> chains.
>
> Another possible strategy is to export the current String hashing
> algorithm into some public method and make the JLS rely on that
> method. Eh, I don't like it, but it's a theoretical option.
>
> Paul
>
>