What are the consequences of not following equals and hashCode contract

[Mahtab Alam]

class Weird
{
   String status;
   Weird(String s){status=s;}
  public boolean equals(Object o)
  {
       if(o instanceof Weird && ((Weird)o).status.charAt(0)==this.status.charAt(0) )
	   {
	    return true;
		}
		else
		{
		return false;
		}
  }
  public int hashCode()
  {
     return status.length();
  }
  
  public static void main(String args[])
  {
      Weird w1=new Weird("Feeling Good");
	  Weird w2=new Weird("Feeling Bad");
	  System.out.println(w1.equals(w2));
	  
  }
  

}

So what if we don`t follow equals and hashCode contract that hashCode must return true if equals return true for two objects.

[William Brogden]

If you do not implement equals and hashCode correctly various "Collections" classes will fail to work as expected.

Bill

[Jesper de Jong]

Especially hash-based collections such as HashSet and HashMap.

For example: you put an object with incorrect hashSet() and equals() methods in a HashSet, and then when you check if it's in the HashSet, it will tell you it isn't there, even though you just put it in.

What happens exactly depends on the details of how collections such as HashSet and HashMap are implemented, and it's in general not easily possible to predict what will happen. The only thing that's important to remember if that these collections might not do what you expect if you put in objects that have incorrectly implemented hashSet() and equals() methods.

[Campbell Ritchie]

Let's have a class Foo which correctly overrides equals and not hashCode

Foo f1 = new Foo("Campbell");
Foo f2 = new Foo("Campbell");
System.out.printf("f1.equals(f2): %b%n", f1.equals(f2)); //prints true
Set<Foo> fooSet = new HashSet<>();
fooSet.add(f1);
System.out.printf("fooSet.contains(f2): %b%n",
      fooSet.contains(f2)); //probably prints false
fooSet.add(f2);
System.out.printf("fooSet.size(): should be 1: %d%n",
     fooSet.size()); //probably prints 2

This is unpredictable; there is a 1 in 16 chance that you will get true-true-1!

[Mahtab Alam]

import java.util.*;
class Weird
{
   String status;
   Weird(String s){status=s;}
  public boolean equals(Object o)
  {
       if(o instanceof Weird && ((Weird)o).status.charAt(0)==this.status.charAt(0) )
	   {
	    return true;
		}
		else
		{
		return false;
		}
  }
  public String toString(){return status;}
  public int hashCode()
  {
     return status.length();
  }
  
  public static void main(String args[])
  {
      Weird w1=new Weird("Feeling Good");
	  Weird w2=new Weird("Feeling Bad");
	  Weird w3=new Weird("Feeling Bad");
	  Weird w4=new Weird("Feeling Good");
	  System.out.println(w1.equals(w2));
	  
	  HashSet<Weird>set=new HashSet<Weird>();
	  set.add(w1);
	  set.add(w2);
	  set.add(w3);
	  set.add(w4);
	  
	  System.out.println(set);
	  
  }
  

}

Set does not allow duplicates , now how will set find out whether two weird objects are same or not.
The output of above program just shows two objects .

[Dave Tolls]

All those instances of Weird are equal (according to the equals method).
However, according to hashCode they are not (based on the length of their status).
Consequently where you should have only the one entry in the HashSet you now have two.

[Campbell Ritchie]

Mahtab Alam wrote:

//...
  public boolean equals(Object o)
  {
       if(o instanceof Weird && ((Weird)o).status.charAt(0)==this.status.charAt(0) )
	   {
	    return true;
		}
		else
		{
		return false;
		}
  }
// ...

...

Don't use if (something) return somethngElse; else return somethingDifferent;

In the case of a boolean simply write
return o instanceof Weird && ...;

It's all in the old code conventions. I wish they would update those conventions rather than label them as out of date.