Benefit from computing String Hash at compile time?

[Osvaldo Pinali Doederlein]

Em 18/12/2009 23:42, Paul Benedict escreveu:
> 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.
>    

The hashcode algorithm has changed only once, in 1.2, I checked it too. 
And yes, there's not formal guarantee yet that it won't change again; 
but all it takes is a single line of javadoc, stating that the algorithm 
- which is _already documented and contractual_ at least since 1.2 - 
won't ever change again. Even independent cleanroom implementations (I 
checked GNU Classpath), use the same algorithm.

A+
Osvaldo