Benefit from computing String Hash at compile time?

[Jonathan Gibbons]

Paul Benedict wrote:
> 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
>
>   

Note that specification of String.hashCode specifies how the value is to 
be determined, and that as a result, this is covered by the TCK (JCK) 
which checks for conformance with the specification.  For an impl of 
Java to be called "Java" it must the TCK, and so must pass the tests 
that check for the correct functioning of String.hashCode.  

-- Jon