-1

This is my understanding about hashcode and equals method :

  • if obj1.hashcode == obj2.hashcode (returns true) then obj1.equals(obj2) returns true and
  • if obj1.equals(obj2) returns false (returns true) then obj1.hashcode == obj2.hashcode (returns false)

is this correct?

user1079065
  • 2,085
  • 9
  • 30
  • 53
  • Wait a minute. How is this a duplicate? – Makoto Aug 09 '14 at 19:57
  • @Makoto, the linked Q&A explains the contract between the two exactly. So I don't know how this is *not* a duplicate. The answer to the OP's question is there. But hey, feel free to vote to reopen this question. – Bart Kiers Aug 09 '14 at 20:00
  • Well...from what I read of this question and the (formerly) linked duplicate, one is talking about pitfalls when implementing `equals`/`hashCode`, and this one is talking about an understanding of `equals`/`hashCode`. I don't see how the *question* is duplicated there. – Makoto Aug 09 '14 at 20:01
  • 1
    @Makoto the first and accepted answer identifies why `a.equals(b)` is true that `a.hashCode() == b.hashCode()`. Reading that answer should allow one to answer the 'is this correct?' question for one's self. If you continue to read (down in the depths of the answers), the one by [Khaled](http://stackoverflow.com/a/15599729/289086) specifically addresses the logical statement that is answered in this question. –  Aug 09 '14 at 20:01
  • This answers your qustion pretty much: [Overriding equals and hashCode in Java](http://stackoverflow.com/questions/27581/overriding-equals-and-hashcode-in-java) – kajacx Aug 09 '14 at 20:06
  • @owlstead The relationship question is one that has answers that directly pertain to this one. Further understanding can be found by following those dups. The accepted answer to that question would be an answer to this one. The question "overriding equals and hashCode in Java" was originally the dup target, however that got reopened because its not an exact duplicate. –  Aug 10 '14 at 00:06
  • @owlstead for that I would refer you to MSE: [Does the new guidance on duplicate questions suggest closing a question as duplicate, if the original answers the OP's question?](http://meta.stackexchange.com/q/217401/) Note the wording on the duplicate message is "This question already has an answer here". Also look at [Changes to “close as duplicate” (part deux)](http://meta.stackexchange.com/q/166707/) in which its stated that "Now, notice that this is subtly different from saying "If that other question isn't asking the exact same thing as yours." That's because the proof is in the answers." –  Aug 10 '14 at 00:33
  • @MichaelT Ah, I get it. As long as the dupe isn't deleted this works. And this is an exact dupe of the question, so -1 votes are also acceptable. Thanks for bearing with me on this one, missed the memo :) – Maarten Bodewes Aug 10 '14 at 00:51
  • 1
    @owlstead No problem. In the "as as long as the dup isn't deleted" - something that useful to do for 10k+ (can can see the deleted targets) is to go through [this query](http://data.stackexchange.com/stackoverflow/query/177487/find-duplicates-of-deleted-posts) and flag questions that have been deleted and are targets of a deleted post to be undeleted (and possibly historically locked), or retarget the dup, or delete them too. –  Aug 10 '14 at 01:11

3 Answers3

1

if obj1.hashcode == obj2.hashcode (returns true) then obj1.equals(obj2) might return true

From the javadoc

  • 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 hash tables
Sotirios Delimanolis
  • 274,122
  • 60
  • 696
  • 724
1

The convention between equals() and hashCode() mandates this:

  • If an object is determined to be equal, then their hash code must* be equal. That is to say, if obj1.equals(obj2), then obj1.hashCode() == obj2.hashCode().

  • If an object is determined to not be equal, then there is no hard-and-fast rule for what their hash code should be between them. They could return the same hash code, but this may cause a multitude of errors.

*: This "must" is actually unenforceable at compile time or run time, so take it with a grain of salt. Just note that you jeopardize the correctness of your application with equals/hashCode usage if it is not implemented correctly.

Makoto
  • 104,088
  • 27
  • 192
  • 230
  • 1
    Could you reword the 'convention' to 'contract'? Its more than a [convention](http://en.wikipedia.org/wiki/Coding_conventions) which typically covers file structure, indents, comments, naming (getX/setX is a convention). The equals and hashCode relationship is more of a contract - it *must* work this way for things to work. I'll point out that "contract" is specifically used on the second line of the description - "The general contract of hashCode is:" –  Aug 13 '14 at 15:07
1

That is incorrect. The documentation for Object.equals(Object) has a formal explanation of the contract for extending this method. Essentially the intent for the Object.equals method is to check if two objects are actually the same object. However it often makes sense to override this functionality and instead make your class' equals method determine whether two objects are logically equal to each other (for example, two different instances of String objects which both represent the same sentence).

On the other hand, Object.hashCode() specifies the following contract:

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 hash tables.

As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the Java™ programming language.)

Basically, two different objects (either logically different or technically distinct) may have the same hashcode, because of how hashcodes are designed, but they should not be "equals". However, if two objects are equal to each other, they must have the same hashcode. Similarly, an object's hashcode may only change if the object itself changes in some way.

For further reading, see the Wikipedia article on hash functions.

muffin
  • 668
  • 1
  • 6
  • 13