Benefit from computing String Hash at compile time?

[Paul Benedict]

Reinier,

Thank you for your reply.

On Fri, Dec 18, 2009 at 5:04 PM, Reinier Zwitserloot
<reinier at zwitserloot.com> wrote:
> String.hashCode() has _already_ been defined as unchanging and set in stone.
> We could do so again, if it assuages recently stated fears, though I'm not
> sure what this would accomplish. It's right here:
> http://java.sun.com/javase/6/docs/api/java/lang/String.html#hashCode()

I hope to make some things clear:

My objection relies solely on the fact that it is not "set in stone".
If I remember correctly, Joe had to do research if the API ever
changed (not since at least 1.2). Neither Joe, Jonathan, and Josh
(people well respected) have claimed what you are claiming. The
highest assurance given is that it's "highly unlikely" and only if
"hell freezes over". .

Now I grant the fact it's highly unlikely. I buy off on that. The odds
are hashCode() is not going to change. I also have no philosophical
problems with emitting the value from String.hashCode() into class
files. However, I believe the manufacturer of a JDK should have
*absolute certainty* when making this decision. It's pretty clear to
me this certainty is high, but not absolute. And since OpenJDK is made
by Sun, the bearer of Java, if it is good for them, it's good for
everyone. Follow the leader. Once this decision is made, I assert
String.hashCode() will have to be "set in stone" but only because of
Project Coin and Sun's influence, not the API.

Paul