Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!news-out.readnews.com!transit3.readnews.com!news-out.news.tds.net!newsreading01.news.tds.net!53ab2750!not-for-mail From: "Eric Sosman" Subject: Re: hashCode Message-ID: <50269FD1.56652.calajapr@time.synchro.net> X-Comment-To: bob smith Newsgroups: comp.lang.java.programmer In-Reply-To: <50269FCE.56638.calajapr@time.synchro.net> References: <50269FCE.56638.calajapr@time.synchro.net> X-FTN-AREA: COMP.LANG.JAVA.PROGRAMMER X-FTN-MSGID: 1:261/38 17a68ee8 X-FTN-REPLY: 1:261/38 225e14ea Content-Type: text/plain; charset=IBM437 Content-Transfer-Encoding: 8bit X-Gateway: time.synchro.net [Synchronet 3.16a-Win32 NewsLink 1.98] Lines: 70 Date: Sat, 11 Aug 2012 18:17:54 GMT NNTP-Posting-Host: 69.21.70.65 X-Complaints-To: news@tds.net X-Trace: newsreading01.news.tds.net 1344709074 69.21.70.65 (Sat, 11 Aug 2012 13:17:54 CDT) NNTP-Posting-Date: Sat, 11 Aug 2012 13:17:54 CDT Organization: tds.net Xref: csiph.com comp.lang.java.programmer:17704 To: bob smith From: Eric Sosman On 8/10/2012 6:22 PM, bob smith wrote: [... many blank lines removed for legibility's sake ...] > On Friday, August 10, 2012 11:34:28 AM UTC-5, Eric Sosman wrote: >> On 8/10/2012 11:47 AM, bob smith wrote: >> >>> Is it always technically correct to override the hashCode function like so: >>> >>> @Override >>> public int hashCode() { >>> return 1; >>> } >>> >>> Would it be potentially better if that was Object's implementation? >> >> Define "better." > > 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. I cannot think of a case where you HAVE to override hashCode(), except as a consequence of other choices that you didn't HAVE to make. You don't HAVE to invent classes where distinct instances are considered equal, and even if you do you don't HAVE to put those instances in HashMaps or HashSets or whatever. But that's a bit specious: All it says is that you don't HAVE to override hashCode() because you don't HAVE to use things that call it. It's like "You don't HAVE to pay taxes, because you don't HAVE to live outside prison." So, let's take it as a given that you will often need to write classes that override equals() and hashCode() -- I imagine you understand that they go together. Okay: Then returning a constant 1 (or 42 or 0 or whatever) would in fact satisfy the letter of the law regarding hashCode(): Whenever x.equals(y) is true, x.hashCode() == y.hashCode(). In your example this would be trivially true because x,y,z,... all have the same hashCode() value, whether they're equal or not -- You have lived up to the letter of the law. Of course, such a hashCode() would make all those hash-based containers pretty much useless: They would work in the sense that they would get the Right Answer, but they'd be abominably slow, with expected performance of O(N) instead of O(1). See for a survey of some denial-of-service attacks that work by driving hash tables from O(1) to O(N), resulting in catastrophic failure of the attacked system. In other words, the letter of the law on hashCode() is a bare minimum that guarantees correct functioning, but it is not enough to guarantee usability. Why isn't the law more specific? Because nobody knows how to write "hashCode() must be correct *and* usable" in terms that would cover all the classes all the Java programmers have dreamed up and will dream up. Your hashCode() meets the bare minimum requirement, but is not "usable." The actual hashCode() provided by Object also meets the bare minimum requirement, and *is* usable as it stands, until (and unless; you don't HAVE to) you choose to implement other equals() semantics, and a hashCode() to match them. -- Eric Sosman esosman@ieee-dot-org.invalid --- BBBS/Li6 v4.10 Dada-1 * Origin: Prism bbs (1:261/38) --- Synchronet 3.16a-Win32 NewsLink 1.98 Time Warp of the Future BBS - telnet://time.synchro.net:24