Re: what the benefit is by using annotation, like "@Immutable" ?
"Lew" <noone@lewscanon.com> wrote in message
news:i209tj$90n$1@news.albasani.net...
Peter Duniho wrote
And, also presumably, this is the same thinking that led to the code
in which those unfortunate strings with a hash code of 0 always wind
up getting recalculated no matter what (because otherwise, one would
need a flag, separate from the hash code field, which could wind up
out-of-sync with the hash code field absent synchronization, such as
"volatile"???as discussed previously in this thread).
Mike Schilling wrote:
Or simply giving them an arbitrary different value for hashCode() (e.g.
1), which is vanishingly unlikely to create any problems. (Though it
does break the explicit contract of String.hashCode(), which would need
to be changed.)
I'm still not clear on what makes 1 or 42 or 17 or any other value
significantly "better" than 0. One might as well use 0, since likely the
only String with a hash to be recalculated each time in practice will be
"", and as others have pointed out, that one is very quick to recalculate.
If 0 means "I haven't calculated it yet", and a calculated value of 0 is
stored as 1, you never need to recalculate. I don't mind if you change it to
17182891 to mean "I haven't calculated it yet", and store a calculated value
of 17182891 as 23023492348. It's the same thing -- you never need to
recalculate,