Path: csiph.com!usenet.pasdenom.info!gegeweb.org!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: Jim Janney Newsgroups: comp.lang.java.programmer Subject: Re: hashCode Date: Fri, 31 Aug 2012 14:38:12 -0600 Organization: dotting one eye and crossing the other Lines: 47 Message-ID: References: <563f186a-edb3-4311-ae48-3af7decfce2c@googlegroups.com> <50317b03$0$281$14726298@news.sunsite.dk> <503bfd0f$0$282$14726298@news.sunsite.dk> <3zc%r.5945$pd4.2658@newsfe21.iad> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx04.eternal-september.org; posting-host="75975abe3fe3503ca7350803ab98e478"; logging-data="10909"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/Rmpa6389BN4LPnyQY1AgV" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) Cancel-Lock: sha1:yj9v8G/75vqEEgZuNyC5FElmK3Q= sha1:EA5uiPRFx8+QD945iYhEftQIgHA= Xref: csiph.com comp.lang.java.programmer:18486 Eric Sosman writes: > On 8/31/2012 11:56 AM, Jim Janney wrote: >> Eric Sosman writes: >>[...] >>>> Objects that compare equal must hash to the same value. It follows that >>>> if the hash function uses a value, so must the comparison method. >>> >>> Since java.lang.String had already been mentioned, it's sort >>> of too bad you didn't look at it before posting. Had you done so, >>> you'd have found that [1] hashCode() uses the private field `hash' >>> and [2] equals() does not. >> >> If you want to play gotcha, it's sort of too bad you don't read this >> newsgroup more often. I pointed out the use of the private field some >> time ago, when we were discussing immutable classes. >> >> If you'd rather argue on the actual issues, a cached result is not extra >> information. The hashCode method in String doesn't return anything that >> can't be computed from publically available information. > > Right. Except hashCode() can arrange to compute the value > just once, while an external Hasher without access to the private > field would need to recompute it every single time. I never said > a Hasher could not compute a perfectly good hash code (for a sane > class, at any rate), just that it would have to forego benefits > that are available to an internal hashCode() method. > > Are those benefits worth while? Sometimes yes, sometimes no. > Sun apparently believed that they were in fact worth while in the > case of java.lang.String (indeed, Bloch says String's hashCode() > received a lot of attention and went through multiple generations). > If you think caching String's hash is not worth the effort, I > encourage you to experiment with a variant rt.jar that omits the > cache, run some timings, and report the results. I certainly think that the performance gained from caching matters. But your objection is without substance: once again, there is no reason why String can't define a hashCode method for instances of Hasher to call. No need to forego anything. And String is very much an unusual case: it's final, immutable, and frequently used as a hash key. Not many other classes will fall into that category. -- Jim Janney