public Employee
{
   public boolean equals(Object other)
   {
      if (getClass() != other.getClass()) return false;
      // cast other to Employee and compare fields
      . . .
   }
}

What bugs me is how many programmers do something different and dangerous, and how many authors egg them on. If you look at the implementations of equals in the source of the standard library (about 150), you will find that the majority use an instanceof test instead.

public Employee
{
   public boolean equals(Object other)
   {
      if (!(other instanceof Employee)) return false;
      // cast other to Employee and compare fields
      . . .
   }
}

This is a crummy idea. In many (most?) cases, a subclass will want to override equals by comparing the superclass fields and the subclass fields, like this:

public Manager extends Employee
{
   public boolean equals(Object other)
   {
      . . . 
      if (!super.equals(other)) return false;
      // cast other to Manager and compare fields
      return bonus == ((Manager)other).bonus;
   }
}

But now equals has become seriously asymmetric:

• anEmployee.equals(aManager) compares true if the employee and manager have the same superclass data
• aManager.equals(anEmployee) throws an exception

Why don't more authors mention this?

For example, Josh Bloch has a chapter on equals in his Effective Java book, and he never once mentions the getClass() != other.getClass() test.

Instead, he pontificates about a rather pointless example with Point and ColoredPoint classes where equals does not take the point's colors into consideration.

Why is there a stubborn refusal in the Java literature to recognize the obvious?

• You should almost always test for getClass() != other.getClass() in an equals method
• There is a small number of cases where instanceof makes sense, namely if
  
• a superclass has fixed the semantics for equals
• the state of various subclasses differ in inessential ways from the state of the superclass
• and the subclasses can add value by redefining equals to be more efficient
  
This is the case in the java.util.Collection hierarchy.

public Employee{
   public boolean equals(Object other)
   {
      if (this == other) return true;
      if (other == null) return false;
      if (getClass() != other.getClass()) return false;
      // cast other to Employee and compare fields
      . . .   }
}

> public Employee{
>   public boolean equals(Object other) {
>     if (this == other) return true;
>     if (other == null) return false;
>     if (getClass() != other.getClass()) return false;
>     // cast other to Employee and compare fields
>   }
> }

public boolean equals(Object other)
{
  if (this == other) {
    return true;
  } else if (other == null) {
    return false;
  } else if (getClass() != other.getClass()) {
    return false;
  } else {
    // cast other to Employee and compare fields
  }
}

public boolean equals(Object other)
{
  boolean result = false;
 
  if (this == other) {
    result = true;
  } else if (other == null) {
    result = false;
  } else if (getClass() != other.getClass()) {
    result = false;
  } else {
    // cast other to Employee and compare fields
  }
  return result;
}

if ( m.getPerson().equals(e.getPerson()) )...