That may not be as simple as it seems to you. Consider two classes A and B
which do not have any semantical interrelation but have similar fields:

class A {
   int num1;    // significant for equals
   String name; // NOT significant

   public boolean equals(Object obj) {
       if(this == obj)
           return true;
       if((obj == null) || (obj.getClass() != this.getClass()))
           return false;

       A a =  (A) obj;
           return num1 == a.num1;
   }

   public int hashCode() {
       int hash = 7;
       hash = 31 * hash + num1;
       return hash;
   }

}

class B {
   int num2;    // significant for equals
   Date date; // NOT significant

   public boolean equals(Object obj) {
       if(this == obj)
           return true;
       if((obj == null) || (obj.getClass() != this.getClass()))
           return false;

       B b =  (B) obj;
           return num2 == b.num2;
   }

   public int hashCode() {
       int hash = 7;
       hash = 31 * hash + num2;
       return hash;
   }

}

If instances of A and B have the same value in their num1/num2 field, their
hashcode is the same but they are not equal. How do you want to make sure
the hashCodes are distinct in this case? And this is a pretty obvious case
so you could raise the plea that changing one of the hashCode calculations
could solve the problem. But some other hashCode method could return the
same value with a complete different computation.

And there is an even simpler example:

class C {
   int num1;
   int num2;

   equals...

   public int hashCode() {
       int hash = 7;
       hash = 31 * hash + num1;
       hash = 31 * hash + num2;
       return hash;
   }
}

If num1 and num2 are significant fields, that you involve in the calculation
of hashCode you cannot distinguish between two instances c1 (num1 = 3, num2
= 4) and c2 (num1 = 4, num2 = 3) with the given hashCode method. There might
be a possibility, e.g.

   public int hashCode() {
       int hash = 7;
       hash = 31 * hash + num1;
       hash = 32 * hash + num2;
       return hash;
   }

but I am not sure if this implementation does really calculate distinct
codes. Proofing this could be difficult especially if many fields are
involved in the calculation.

You cannot guaranty distinct hashCodes over several classes. While it is
expensive to do that for your own classes it is impossible if you add
classes that are not under your control.

Regards
Sebastian

It might not always be possible since there are only
2^32 possible hashCode values.  So you'd be stuck
if you tried to do this for String values, since there
are many many more than 2^32 possible strings
values.

I disagree. The simplest way is to give the -same- value for every instance.

public int hashCode() {
   return 0;
}

Greetings, Leon.

Even when the semantic space is small enough to fit into 32 bits,
computing a perfect hash is often expensive.  If its cheap for your
class, then by all means compute it and compare the hash and type for
equalilty.  Domains that would meet this criteria would be byte[4]
arrays or java.lang.Integer.

As far as the contract for hashCode() goes, the value it returns does
not have to be unique. In fact we can not and must not rely upon the
hashCode being unique.  hashCode is not an identifier of the object

Its worth knowing that its common for two instances of unrelated classes
to produce the same hashCode value.

The purpose of hashCode is for hashing efficiency used by HashSet,
HashTable, HashMap, etc.

In general, the hashCode is used to determine which bucket the object is
placed in, so that fast retrival can occur because we don't have to
compare every element within the collection, just every element within
the bucket.

here's the HashMap.containsKey() method showing the retrival and
comparisons of each entry with the bucket.

   */
    public boolean containsKey(Object key) {
        Object k = maskNull(key);
        int hash = hash(k);
        int i = indexFor(hash, table.length);
        Entry e = table[i];
        while (e != null) {
            if (e.hash == hash && eq(k, e.key))
                return true;
            e = e.next;
        }
        return false;
    }

The advice wrt to overriding equals() is that you should also override
hashCode() to ensure the efficiencies of the hashing algorithms.

This might work, but is not a good general practise, consider...

Class Person {

  private String forename;
  private String surname;

  public Person(String theirName, String theirSurname) {
    name = theirName;
    surname = theirSurname;
  }

  public int hashCode() {
    return foreName.hashCode() + surname.hashCode();
  }

  public boolean equals(Object o) {
    Person other = (Person) o;
    return other.hashCode() = this.hashCode();
  }

}

if the created two instances with different values, but reversed..

Person p1 = new Person("Andrew", "John");
Person p2 = new Person("John", "Andrew");

its possible that the hashCode value for both objects would be the same
and so if we used the hashCode as an equality comparitor, a false
positive would result.

Always, start with creating the equals method, then make the hashCode work.