AppletTalk.com Java discussions newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  hashCode Goto page 1, 2, 3, 4, 5, 6, 7, 8, 9  Next          AppletTalk.com Forum Index -> Java Language Programming View previous topic :: View next topic   Author Message bob smith Guest Posted: Fri Aug 10, 2012 3:47 pm    Post subject: hashCode 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? Back to top Arne Vajhøj Guest Posted: Fri Aug 10, 2012 3:47 pm    Post subject: Re: hashCode On 8/10/2012 11:47 AM, bob smith wrote: Quote: Is it always technically correct to override the hashCode function like so: @Override public int hashCode() { return 1; } It meets the minimum contractual obligation for that method. But performance of anything using the hash capability (like HashMap<>) would be very bad. Quote: Would it be potentially better if that was Object's implementation? It has a different behavior that may not be valid if you override equals. Arne Back to top Eric Sosman Guest Posted: Fri Aug 10, 2012 3:47 pm    Post subject: Re: hashCode On 8/10/2012 11:47 AM, bob smith wrote: Quote: 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." -- Eric Sosman esosman@ieee-dot-org.invalid Back to top markspace Guest Posted: Fri Aug 10, 2012 3:47 pm    Post subject: Re: hashCode On 8/10/2012 9:13 AM, Arne Vajhøj wrote: Quote: 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; } It meets the minimum contractual obligation for that method. But performance of anything using the hash capability (like HashMap<>) would be very bad. Would it be potentially better if that was Object's implementation? It has a different behavior that may not be valid if you override equals. I think at this point we are doing Bob's homework for him. Back to top Arne Vajhøj Guest Posted: Fri Aug 10, 2012 3:47 pm    Post subject: Re: hashCode On 8/10/2012 1:13 PM, markspace wrote: Quote: On 8/10/2012 9:13 AM, Arne Vajhøj 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; } It meets the minimum contractual obligation for that method. But performance of anything using the hash capability (like HashMap<>) would be very bad. Would it be potentially better if that was Object's implementation? It has a different behavior that may not be valid if you override equals. I think at this point we are doing Bob's homework for him. Could be. But I think the question whether returning a constant from hashCode is a valid Java question for understanding the contract for that method. And I am pretty sure that I have seen other similar examples (just with 42 as constant). Arne Back to top Roedy Green Guest Posted: Fri Aug 10, 2012 5:17 pm    Post subject: Re: hashCode On Fri, 10 Aug 2012 08:47:12 -0700 (PDT), bob smith <bob (AT) coolfone (DOT) comze.com> wrote, quoted or indirectly quoted someone who said : Quote: @Override public int hashCode() { return 1; } that's about the worst possible hashCode function. See http://mindprod.com/jgloss/hashcode.html for tips on how to write good ones. -- Roedy Green Canadian Mind Products http://mindprod.com A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grows up that is familiar with it. ~ Max Planck 1858-04-23 1947-10-04 Back to top Lew Guest Posted: Fri Aug 10, 2012 7:45 pm    Post subject: Re: hashCode Roedy Green wrote: Quote: bob smith wrote, quoted or indirectly quoted someone who said : @Override public int hashCode() { return 1; } that's about the worst possible hashCode function. Normally that's correct, but it's conceivable that one might do it for some hackish reason. In most situations where one might do such an override as this, one would do better not to override hashCode(). Quote: See http://mindprod.com/jgloss/hashcode.html for tips on how to write good ones. The default of assembling it via the mix-in of attribute hash codes using the Knuth constants is usually good enough. h(object) = Sum(i ∈ 0.. n-1) of ( attribute[i] * pow(31, n - 1 - i) ); or public static int calculateHash(Foo arg) { int h = 0; for ( each attribute of Foo that contributes to 'equals()' ) { h = 31 * h + attribute.hashCode(); } return h; } http://en.wikipedia.org/wiki/Hash_function http://en.wikipedia.org/wiki/Java_hashCode() http://en.wikipedia.org/wiki/Java_hashCode()#Java -- Lew Back to top Arne Vajhøj Guest Posted: Fri Aug 10, 2012 9:25 pm    Post subject: Re: hashCode On 8/10/2012 3:17 PM, Roedy Green wrote: Quote: On Fri, 10 Aug 2012 08:47:12 -0700 (PDT), bob smith bob (AT) coolfone (DOT) comze.com> wrote, quoted or indirectly quoted someone who said : @Override public int hashCode() { return 1; } that's about the worst possible hashCode function. Yes, but the posted asked "Is it always technically correct to ..." not whether is was "best possible". Arne Back to top Arne Vajhøj Guest Posted: Fri Aug 10, 2012 9:27 pm    Post subject: Re: hashCode On 8/10/2012 6:22 PM, bob smith wrote: Quote: 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. It is not broken. It will perform poorly in many cases. Arne Back to top Arne Vajhøj Guest Posted: Fri Aug 10, 2012 9:30 pm    Post subject: Re: hashCode On 8/10/2012 6:32 PM, Lew wrote: Quote: 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. Arne Back to top bob smith Guest Posted: Fri Aug 10, 2012 10:22 pm    Post subject: Re: hashCode On Friday, August 10, 2012 11:34:28 AM UTC-5, Eric Sosman wrote: Quote: 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." -- Eric Sosman esosman@ieee-dot-org.invalid 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. Back to top Lew Guest Posted: Fri Aug 10, 2012 10:32 pm    Post subject: Re: hashCode bob smith wrote: Quote: Eric Sosman wrote: bob smith wrote: Is it always technically correct to override the hashCode function like so: It complies with the contract for 'hashCode()'. Is that all it takes to be correct? Quote: Would it be potentially better if that was Object's implementation? Would what be better if what were Object's implementation of what? Quote: 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. No. No matter what 'Object''s 'hashCode()' implementation were, it would need to be overridden when you want value equality instead of object identity for 'equals()'. See Joshua Bloch's seminal work /Effective Java/, which has items that pertain to this. Bottom line: 'hashCode()', 'equals()', and when present, 'compareTo()' must be consistent. 'toString()' should be consistent with those. 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. -- Lew Back to top rossum Guest Posted: Sat Aug 11, 2012 7:36 am    Post subject: Re: hashCode On Fri, 10 Aug 2012 13:38:19 -0400, Arne Vajhøj <arne (AT) vajhoej (DOT) dk> wrote: Quote: And I am pretty sure that I have seen other similar examples (just with 42 as constant). The magic word is "Bloch". rossum Back to top Roedy Green Guest Posted: Sat Aug 11, 2012 9:54 am    Post subject: Re: hashCode On Fri, 10 Aug 2012 12:45:07 -0700 (PDT), Lew <lewbloch (AT) gmail (DOT) com> wrote, quoted or indirectly quoted someone who said : Quote: h =3D 31 * h + attribute.hashCode(); } In my essay I recommend XOR which is an inherentely faster operation than multiply. I wonder which actually works out better. If you had a large number of fields, the multiply effect could fall off the left hand end. It is the algorithm used for String which could have very long strings, so Sun must have thought of that. -- Roedy Green Canadian Mind Products http://mindprod.com A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grows up that is familiar with it. ~ Max Planck 1858-04-23 1947-10-04 Back to top Eric Sosman Guest Posted: Sat Aug 11, 2012 9:58 am    Post subject: Re: hashCode On 8/10/2012 6:22 PM, bob smith wrote: [... many blank lines removed for legibility's sake ...] Quote: 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 <http://www.cs.rice.edu/~scrosby/hash/CrosbyWallach_UsenixSec2003/> 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 Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         AppletTalk.com Forum Index -> Java Language Programming All times are GMT Goto page 1, 2, 3, 4, 5, 6, 7, 8, 9  Next Page 1 of 9   Jump to: Select a forum Java Newsgroups----------------Java DiscussionsWeb-based java games comp.lang.java 3D Graphics API's for Java Java: Support and criticism Java System Announcements comp.lang.java.api JavaBeans Java and CORBA Java and Databases comp.lang.java.developer Java GUI Toolkits Java Help comp.lang.java.javascript JVM, native methods and hardware comp.lang.java.misc Java Language Programming Security and Java comp.lang.java.setup Java Software Tools comp.lang.java.tech ibm.software.java.linux  Non-English Java Newsgroups----------------Java Language (German)Language Java (Français)Java (Italian)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.