0

So this is from Head First Java (page 563)

The default behaviour of hashCode() is to generate a unique integer for each object on the heap. So if you don’t override hashCode() in a class, no two objects of that type can EVER be considered equal.

But a simple Test will disprove this I think.

public class Song { private String name; public Song(String name) { this.name = name; } public String getName() { return name; } @Override public boolean equals(Object obj) { Song objectSong = (Song) obj; return this.getName().equals(objectSong.getName()); } }

Well this will return true:

Song songA = new Song("A","B"); Song songB = new Song("A","C"); System.out.println(songA.equals(songB));

Am I missing something? What is it that the book is trying to tell me?

Improve this question
6
  • Right before the part you cited it says "if you override equals(), you MUST override hashCode()". Commented Jul 7, 2014 at 4:41
  • @Robert Sorry, I do not understand, what are you trying to tell with this comment? Commented Jul 7, 2014 at 4:50
  • On page 563 it says "if you override equals(), you MUST override hashCode()" and "if you don't override hashCode(), no two objects can be considered equal". So if you don't override hashCode(), you MUST NOT override equals(), and hence no two objects can be considered equal. Commented Jul 7, 2014 at 5:05
  • @Robert In my question I am proving that I can make 2 objects to be considered equal without overriding hashcode? Commented Jul 7, 2014 at 7:07
  • Yes, in your question you are proving that it's possible to override equals() without overriding hashCode(). I only wanted to point out that the book states on the same page that it's not correct to do so. Commented Jul 7, 2014 at 11:58

3 Answers 3

Reset to default
2

The default behaviour of hashCode() is to generate a unique integer for each object on the heap. So if you don’t override hashCode() in a class, no two objects of that type can EVER be considered equal.

You're misinterpreting. The author isn't saying that a method (that's all equals and hashCode are) can't return true for two different objects. They're saying that semantically two objects should not be considered equal if the result of their hashCode isn't equal. They are describing how hashCode should be used. If you use it differently, you may get weird and unexpected results.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

+1. For example a HashSet only considers invoking equals for objects of matching hash code. As long as the hash codes don't match they can't be equal anyway.
1

You need to override hashcode so that the class behaves as expected with hashcode based collections (and anything else).

For example what happens if you put your song in a HashSet, and then try to put another one in ?

You should always override Hashcode if you override equals, and vice versa. Make sure they are consistent.

(josh bloch effective java, is a good starting point)

Improve this answer

Comments

0

In Java, every object has access to the equals() method because it is inherited from the Object class. However, this default implementation just simply compares the memory addresses of the objects. You can override the default implementation of the equals() method defined in java.lang.Object. If you override the equals(), you MUST also override hashCode(). Otherwise a violation of the general contract for Object.hashCode will occur, which can have unexpected repercussions when your class is in conjunction with all hash-based collections.

Source: http://www.xyzws.com/javafaq/why-always-override-hashcode-if-overriding-equals/20 (take a look at it, it has good examples).

Conclusion: you only need to override equals for a simple comparison. However, you SHOULD also override hashCode for other aspects, such as hash based collections.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.