Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!nx02.iad01.newshosting.com!newshosting.com!news-out.readnews.com!transit4.readnews.com!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.56690.calajapr@time.synchro.net> X-Comment-To: Lew Newsgroups: comp.lang.java.programmer In-Reply-To: <5027F2C7.56685.calajapr@time.synchro.net> References: <5027F2C7.56685.calajapr@time.synchro.net> X-FTN-AREA: COMP.LANG.JAVA.PROGRAMMER X-FTN-MSGID: 1:261/38 a2dc94e2 X-FTN-REPLY: 1:261/38 ab2616a3 Content-Type: text/plain; charset=IBM437 Content-Transfer-Encoding: 8bit X-Gateway: time.synchro.net [Synchronet 3.16a-Win32 NewsLink 1.98] Lines: 92 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: 4724 Xref: csiph.com comp.lang.java.programmer:17745 To: Lew From: =?UTF-8?B?QXJuZSBWYWpow7hq?= On 8/11/2012 7:24 PM, Lew wrote: > On 08/10/2012 04:30 PM, Arne Vajh-,j wrote: >> On 8/10/2012 6:32 PM, Lew wrote: >>> bob smith wrote: >>>> Now, there are cases where you HAVE to override it, or your code is >>>> very >>>> broken. >>> >>> No. >> >>> As long as 'hashCode()' fulfills the contract, your code will work - >>> functionally. But a bad >>> 'hashCode()' could and likely will noticeably affect performance. >>> There is >>> more to correctness >>> than mere functional conformance. >> >> If the code per specs is guaranteed to work then it is correct. >> >> Good (or just decent) performance is not necessary for code to >> be correct. >> >> At least not in the traditional programming terminology. >> >> In plain English maybe. > > I see your point, but that is not to say that the specs exclude > performance considerations. > > In the case of 'hashCode()', the Javadocs do say, "This method is > supported for the benefit of hash tables such as those provided by > HashMap." > > > The key question here is how you define "benefit". I argue that a hash > code that is constant does not benefit, say, a 'HashMap' because one of > our desired uses is constant-order retrieval. Object having the method defined to support effective hashing does not imply that it has to it just means that the potential is there. > "This implementation provides constant-time performance for the basic > operations (get and put), assuming the hash function disperses the > elements properly among the buckets." Yes. And here it makes an assumption. Not that hashCode is implemented correct, but that it is implemented in a certain way. > Each specification refers to the other. Ergo they are meant to be > considered together. Taken together, the documentation clearly specifies > that "correct" or "proper" includes performance considerations. > Therefore, by what you say, the simple "return 1;" is not correct. > As you say, Arne, "correct" means it follows the spec. The OP's > suggested implementation violates the spec on two fronts. No it does not. It follows exactly the explicit stated contract in the Java doc: The general contract of hashCode is: Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified. This integer need not remain consistent from one execution of an application to another execution of the same application. If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result. It is not required that if two objects are unequal according to the equals(java.lang.Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results. However, the programmer should be aware that producing distinct integer results for unequal objects may improve the performance of hashtables. The ability to support something does not make it part of the contract. This is a classic test question in basic Java SE. And that returning a constant is correct but not smart should be in most Java SE text books. 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