Benefit from computing String Hash at compile time?

[Jonathan Gibbons]

Paul,

I was reacting to your somewhat wishy-washy description of the 
effectiveness of the specification;

> 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 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.

-- Jon




Paul Benedict wrote:
> Jon,
>
> Thanks. But the issue I raised is not about conforming to the current
> JDK, but whether the algorithm can possibly changing in a future JDK.
> As I said before, these values are written into the class file -- so
> they have to (must, shall, will) conform to ALL future JDK versions.
>
> Paul
>
> On Mon, Jan 4, 2010 at 3:56 PM, Jonathan Gibbons
> <Jonathan.Gibbons at sun.com> wrote:
>   
>> 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
>>
>>
>>     
>
>