Confused about equals & hashcode methods

[Adam Satyres]

Hi , i'm reading K&B book and i'm extreamly confused about equals & hashcode methods !
1)When shoud we use them ?
2) Can we use one of them only ?? equals without hashcode when and why ?
3) Both shoud be used when working with Map ??
this exercice is taken from the book

package Exercices;
import java.util.*;

public class MapEQ {
	
	public static void main(String[] args) {
		Map<ToDos,String> m=new HashMap<ToDos, String>();
		ToDos t1=new ToDos("Monday");
		ToDos t2=new ToDos("Monday");
		ToDos t3=new ToDos("Tuesday");
		m.put(t1, "DoLaundray");
		m.put(t2, "PayBills");
		m.put(t3, "CleanAttic");
		System.err.println(m.size());
		
		
	}
}
class ToDos
{
	String day;
	ToDos(String _d)
	{
		day=_d;
	}
	@Override
	public boolean equals(Object obj) {
		// TODO Auto-generated method stub
		return ((ToDos)obj).day==this.day;
	}
	@Override
	public int hashCode() {
		// TODO Auto-generated method stub
		return 9;
	}
}

when we comment hashcode method we get 3 size of the hashmap , when we remove the comment we get 2 ?
Can anyone please explain why ?
Best regards

[Jeanne Boyarsky]

Adam,
I'm going to start with question #3. Let's look at what happens in that code:

On line 11, Java adds a single key/value pair to the map. On line 12, it tries to use the "same" key. Well, maybe it is the same. HashMap calls hashCode() to see if the hash codes of t1 and t2 are the same. Since they are, it calls the equals() method and sees they are also the same. Since they keys are the same, it overwrites the original value in the map. t3 is clearly a different key so there are two elements in the map.

When you comment out hashCode() this logic breaks down. On line 12, Java sees the hash codes are different. Since there's no way (according to the contract of those methods) that the keys are the same, Java doesn't even bother calling equals(). It just adds the new key to the map. Giving you the extra value.

This means for question #2, you are asking for trouble implementing one and not the other. There is a contract between the two methods and you need to meet it for programs to work.

[Adam Satyres]

Jeanne Boyarsky wrote:Adam,
I'm going to start with question #3. Let's look at what happens in that code:

On line 11, Java adds a single key/value pair to the map. On line 12, it tries to use the "same" key. Well, maybe it is the same. HashMap calls hashCode() to see if the hash codes of t1 and t2 are the same. Since they are, it calls the equals() method and sees they are also the same. Since they keys are the same, it overwrites the original value in the map. t3 is clearly a different key so there are two elements in the map.

When you comment out hashCode() this logic breaks down. On line 12, Java sees the hash codes are different. Since there's no way (according to the contract of those methods) that the keys are the same, Java doesn't even bother calling equals(). It just adds the new key to the map. Giving you the extra value.

This means for question #2, you are asking for trouble implementing one and not the other. There is a contract between the two methods and you need to meet it for programs to work.

Thanks so much for your awesome answer !
but i still have some question
1) When we want to compare 2 object we don't need to use hashcode, as it said in the book , hashcode used to improve the performance ?
2) the contract said the we have to use them both usually even when we have simple compare between object right ?

[Jeanne Boyarsky]

Adam Satyres wrote:When we want to compare 2 object we don't need to use hashcode, as it said in the book , hashcode used to improve the performance ?

I don't think you mean compare here. To compare, you use Comparable or Comparator which doesn't require implementing equals or hashCode.

[Adam Satyres]

Jeanne Boyarsky wrote:

Adam Satyres wrote:When we want to compare 2 object we don't need to use hashcode, as it said in the book , hashcode used to improve the performance ?

I don't think you mean compare here. To compare, you use Comparable or Comparator which doesn't require implementing equals or hashCode.

When we use Comarable or Comparator we will use sort in Collections or Array !
but when we want to see of 2 object are equal we have to use equals ! but hashcode is not always used !
this is the question do i have to override both always

[Paul Anilprem]

Adam Satyres wrote:

Jeanne Boyarsky wrote:

Adam Satyres wrote:When we want to compare 2 object we don't need to use hashcode, as it said in the book , hashcode used to improve the performance ?

I don't think you mean compare here. To compare, you use Comparable or Comparator which doesn't require implementing equals or hashCode.

this is the question do i have to override both always

You are making it too complicated. It is very simple really. Just remember the following two points:
1. You need to override equals if you want to customize the logic that makes two objects of a class equal. For example, you have a class named Account with two attributes name and number, you might want to override the equals method that checks whether the names as well as account numbers of both the objects match.

public class Account {
   private String name, acctNo; //getter/setter omitted for brievity
 
   public boolean equals(Object other){
     if(other != null && other instanceOf Account){
        Account anotherAcct = (Account) other;

        //you can customize this logic however you want.
        return this.name.equals(anotherAcct.name) && this.acctNo.equals(anotherAcct.acctNo);
 
     }else {
        return false;
     }
   }
  
}

If you don't override equals methods, the default one provided by Object class will be used, which just checks if two reference point to the exact same object. It doesn't look into the contents of the objects (like we are doing above).

2. You need to override hashCode only if you want to store and then retrieve objects of your class in any contains that makes use of the hashCode. The name of the container class usually gives that away. For example, if you add Account objects to HashSet or HashMap, you have to override the hashCode method. You should ask the question "why?" at this point and for that, this link should be helpful: http://stackoverflow.com/questions/2265503/why-do-i-need-to-override-the-equals-and-hashcode-methods-in-java

HTH,
Paul.

[Paul Anilprem]

Remember that equals method is public. And if your class is also public, it may be used by other people. They may use your class with hash based containers without consulting you. Therefore, it is a good idea to override the hashCode method at least such that it does not violate the equals-hashCode contract if you override equals method.
As an exercise, try implementing the hashCode method for the equals method I posted above.