Benefit from computing String Hash at compile time?

[Paul Benedict]

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