Benefit from computing String Hash at compile time?

[Reinier Zwitserloot]

I don't really understand the thread of conversation here. The fact that the
algorithm is explained in the javadoc means that it is part of the java
spec. There is no need to explain that it can't ever change; that notion is
already inherent in the fact that the algorithm is explained in the javadoc.
The mistake seems to be in what 'part of the java spec' means. It does not
actually mean: Cannot possibly change.

Like everything else in java that is frozen, pragmatic issues trump
backwards compatibility. String.hashCode was changed in 1.2, as was
explained earlier, because of a conflict in the JVM spec and the javadoc, as
well as a really stupid algorithm in the JVM spec. Pragmatism won out. An
analysis was made of the impact, and the analysis resulted in the decision
to change it, even though that wasn't, technically, backwards compatible.

That was then. At this point in time, it most definitely will not be
changing ever again, regardless of whether string-in-switch has a dependency
on String.hashCode's implementation.

The javadoc of String should also not be bogged down with the implementation
detail that string-on-switch is dependent on it. Implementation details have
no place in javadoc.

--Reinier Zwitserloot



On Sat, Dec 19, 2009 at 2:24 PM, Osvaldo Pinali Doederlein <
opinali at gmail.com> wrote:

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