A DESCRIPTION OF THE REQUEST :
"There is no way to extends an instantiable class and add a value component while preserving the equals contract" (Joshua Bloch's "Effective Java" 2nd edition, p. 38).

The reason is that sub classes' equals() method might consider fields the super class is not aware of. So we get:
Point p = new Point(1,2);
ColoredPoint cp = new ColoredPoint(1,2,Color.RED);  // ColoredPoint extends Point
p.equals(cp); // true
cp.equals(p); // false
(See there for more in-depth discussion)

Proposed solution:
add an at equality operator: @= (pronounces "at equality", so "a @= b" reads "a is at equality with b"). Semantically, "a @= b" is expanded to:
(a == b) || ( (a!=null && a.equals(b)) && (b!=null && (b.equals(a)) )

Optimizations:
1. The runtime or compiler can remove the null checks if they can prove that a or b cannot be null.
2. The runtime can remove one of the equals() invocations, if a and b are instances of the same class.
3. The runtime can remove one of the equals() invocations, if equals() is not overridden between the super class and the sub class.


JUSTIFICATION :
Adding the proposed operator @= to java would:
1. Make it possible to have consistent equality tests when inheritance is used
2. Eliminate a lot of boilerplate code for null tests (as equals() is a method)
3. Allow to "harness developer's laziness" (B. Goetz) for writing better, more robust code


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Point p = new Point(1,2);
ColoredPoint cp = new ColoredPoint(1,2,Color.RED);  // ColoredPoint extends Point
p @= cp; // false

But:
HashSet<Integer> hs = new HashSet<>();
TreeSet<Integer> ts = new TreeSet<>();
hs @= ts; // true
ACTUAL -
Compile error :-)

More seriously, programmers cannot add state fields to subclasses without compromising their ability to use equals() in a consistent way, which also hinders the ability to use the java collections:
Set<Point> pSet = new HashSet<>();
pSet.add( new Point(1,2) );
pSet.add( new ColoredPoint(1,2,Color.RED) );
pSet.size(); // ?? Implementation dependent.


CUSTOMER SUBMITTED WORKAROUND :
Some partial workarounds are possible (see pages 39-44 in Effective Java, 2nd edition).