Benefit from computing String Hash at compile time?

[Jonathan Gibbons]

Alexander Veit wrote:
> Hi Jonathan,
>
>   
>> The fact is, the spec is set in stone, *and* covered by conformance 
>> tests.  The chance of the spec changing is vanishingly small, and the 
>> conformance tests ensure that all implementations of Java must follow 
>> the spec.
>>     
>
> Calculating String#hashCode() is quite costly in terms of CPU cycles. If a
> better performing method with comparable quality would come to our
> knowledge, the chance of changing the spec would probably be greater than e
>   
>> 0.
>>     

Alex,

You are missing the point.   The spec doesn't mandate "a jolly good hash 
function" with enough wiggle room to allow "a jolly better one" if and 
when we think of one. The spec mandates a specific formula. You can 
argue the merits either way of whether it was appropriate to put such a 
specific formula into the spec, but whatever the reason and merits, it 
has happened.  It now has to be assumed that there is Very Important 
Software Out There that is relying on this behavior, and that the Very 
Important Owners of Said Software would be right royally pissed off if 
it were changed.  The chance of the spec changing brings death and taxes 
to mind.

-- Jon