On Thu, 21 Feb 2008 14:59:28 -0800, EJP
<esmond.not.pitt@not.bigpond.com> wrote:
Lew wrote:
Are you sure of that?
Yes.
P.S., please attribute your citations.
The source code.
Or do you think I just make this stuff up?
Well, to be fair: there is in fact a difference between a general
statement such as yours ("the hashCode for a String is computed once
per String") and a qualified statement such as the one Thomas offers
("the sun implementation caches the hash").
Looking at the source code for the Sun implementation doesn't tell
you
what all implementations do, and unless the Java specification
specifically says that all implementations must cache the hash code,
there's no guarantee that they do.
You seem offended by Lew's question, but I think it's a reasonable
one. Is there in fact a genuine guarantee that every implementation
of String will always cache the hash code? Or is this an
implementation-dependent behavior?
Granted, the answer may be academic. It's not like one has much, if
any, control over the behavior and I don't think it's the sort of
thing that should, all else being equal, cause someone to dismiss a
HashMap as a solution.
But we're all programmers here, and as such we often have a need for
being very specific and literal in our understanding of what's being
said. Unless you have some reason to believe that _all_ Java
implementations are _guaranteed_ to cache the hash code, a statement
about what the actual behavior of String is should IMHO be qualified
as Thomas's was, if for no other reason than to offer enhanced
clarity regarding what you're actually saying.
I agree 100% with the points you're making. Anything not guaranteed
always cached the hash code. Moreover, doing so is almost free, and
there are no disadvantages beyond the extra two allocated bytes. (I'm
until I'm shown one that doesn't.