Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: Joshua Cranmer Newsgroups: comp.lang.java.programmer Subject: Re: hashCode Date: Sun, 12 Aug 2012 12:23:24 -0400 Organization: A noiseless patient Spider Lines: 33 Message-ID: References: <563f186a-edb3-4311-ae48-3af7decfce2c@googlegroups.com> <6ac6c252-c370-4f74-b29d-ce5368019977@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sun, 12 Aug 2012 16:23:32 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="905754b2d90668fed142882d531631dc"; logging-data="17255"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/jAjxu42uMi2suzifMnDD7JYPd36uv5cg=" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 In-Reply-To: <6ac6c252-c370-4f74-b29d-ce5368019977@googlegroups.com> Cancel-Lock: sha1:n/7KS1NCdiCeExlI7hPq69n6x7U= Xref: csiph.com comp.lang.java.programmer:17734 On 8/10/2012 6:22 PM, bob smith wrote: > Better in the sense that you would never HAVE to override hashCode. > > Now, there are cases where you HAVE to override it, or your code is very broken. Returning a constant hash code is correct in the same sense that answering "yes" to the question "Can you tell me the correct way to do this?" would be--syntactically and semantically correct, but completely contrary to the actual intent of the question. The point of the hash code is to provide a cheap way to quickly distinguish inputs (in the sense that Pr(a.hashCode() == b.hashCode() and !a.equals(b)) should be as small as possible [1]). A constant-value hash completely negates the purpose of the hash code, and this renders the hashCode again completely unusable for anything that actually wants to use it. In the default case, a.hashCode() == b.hashCode() only when a == b (this definitely holds true with 32-bit machines and I'm pretty sure it still holds true with 64-bit machines, but I'd have to reverify the JVM source code to be certain). It is thus correct so long as identity equals is correct. It is also potentially correct in a limited set of cases where a.equals(b) and a != b. In all of these cases, it would not only be correct but also extremely useful, having pretty strong guarantees about the distribution of hash values. [1] Actually, for good performance, hash codes should go one step further and make slightly stronger guarantees about independence with respect to the size of the hash table. But I digress. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth