Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!news.alt.net!news-in-01.newsfeed.easynews.com!easynews.com!easynews!news-out.news.tds.net!newsreading01.news.tds.net!53ab2750!not-for-mail From: "=?UTF-8?B?QXJuZSBWYWpow7hq?=" <=?utf-8?b?qxjuzsbwywpow7hq?=@1:261/38.remove-m2z-this> Subject: Re: hashCode Message-ID: <5027F2C9.56691.calajapr@time.synchro.net> X-Comment-To: Lew Newsgroups: comp.lang.java.programmer In-Reply-To: <5027F2C8.56686.calajapr@time.synchro.net> References: <5027F2C8.56686.calajapr@time.synchro.net> X-FTN-AREA: COMP.LANG.JAVA.PROGRAMMER X-FTN-MSGID: 1:261/38 6ed2b3ca X-FTN-REPLY: 1:261/38 794ddfcd Content-Type: text/plain; charset=IBM437 Content-Transfer-Encoding: 8bit X-Gateway: time.synchro.net [Synchronet 3.16a-Win32 NewsLink 1.98] Lines: 67 Date: Sun, 12 Aug 2012 18:58:17 GMT NNTP-Posting-Host: 69.21.70.65 X-Complaints-To: news@tds.net X-Trace: newsreading01.news.tds.net 1344797897 69.21.70.65 (Sun, 12 Aug 2012 13:58:17 CDT) NNTP-Posting-Date: Sun, 12 Aug 2012 13:58:17 CDT Organization: tds.net X-Received-Bytes: 3787 Xref: csiph.com comp.lang.java.programmer:17746 To: Lew From: =?UTF-8?B?QXJuZSBWYWpow7hq?= On 8/11/2012 7:29 PM, Lew wrote: > Eric Sosman wrote: >> Okay: Then returning a constant 1 (or 42 or 0 or whatever) >> would in fact satisfy the letter of the law regarding hashCode(): > > Not if you consider all aspects of what the Javadocs promise. > > See my post upthread. > >> 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. > > No, because the law requires that the method support 'HashMap', which in > turn calls for "properly" hashed objects. > >> 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, > > Indeed. > >> 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 > > Actually, if you consider all that the Javadocs tell you, this "letter > of the law" to which you refer is like saying the sequence "ABC" > constitutes all of "the ABCs". > >> 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. > > As Arne states, "correct" means "fulfills the specification". The > specification for Java API methods is the standard Javadocs, which do > impose performance considerations on 'hashCode()'. > > One understands that the spec isn't always fully enforceable by the > compiler. [1] It is correct that the compiler will allow 'return 1;'. It > is not correct that that fulfills the specification. It fulfills the spec. It does not fulfill you bizarre interpretation of "support". Arne --- 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