Benefit from computing String Hash at compile time?

[Paul Benedict]

Reinier,

> There is no need to explain that it can't ever change; that notion is
> already inherent in the fact that the algorithm is explained in the javadoc.
> The mistake seems to be in what 'part of the java spec' means. It does not
> actually mean: Cannot possibly change.

The algorithm is explained. The documentation is good, isn't it? It
is, however, the documentation is for that version of the Java
platform.

> The javadoc of String should also not be bogged down with the implementation
> detail that string-on-switch is dependent on it. Implementation details have
> no place in javadoc.

I agree with you. No one has to reveal implementation details. All
that is necessary is a note that the algorithm must not change from
JDK version to JDK version.

Moving on...
If anyone at Sun is still listening (::grins::), I prefer to emit a
static method that contains a duplicate of the hashCode() algorithm.
Then, no one has to worry about JDK version upgrades and
String.hashCode() is free for future tweaking.

static int $switch_hashCode(String s) {... }
switch ($switch_hashCode(s)) {
...
}

Paul