about point number 3.
I think it is a very bad idea, not overriding the equals() Method.

I think the best thing to do is to understand ones you have changed the object, you have! to remove! the old one from the hash, and enter the new one. yes it might be little less efficient, but it will save you from troubles, and it is logically correct. that is my opinion.

How Joshua Bloch writes there is no general solution when you try to create subclass adding fields that changes the state of entity.
The solution with canEqual looks like a workaround.
In OOP the problem could be solved by separating interface and implementation. Very strange that no one wrote this before, or did I miss something?

interface Point {
  int getX();
  int getY();
}
 
interface ColoredPoint extends Point {
  Color getColor();
}
 
// lombok annotations
@Getter
@AllArgsConstructor
// compare by own fields x, y
@EqualsAndHashCode(of = {"x", "y"})
class PointImpl implements Point {
    private final int x;
    privaet final int y;
}
 
@Getter
@AllArgsConstructor
// compare by own fields point, color
@EqualsAndHashCode(of = {"point", "color"})
class ColoredPointImpl implements ColoredPoint {
    private final Point point; // just delegate getX, getY to point
    private final Color color;
}
 

in that way the equality and Liskov principle could be satisfied.

> The benefit of
> instanceof/canEqual over just using
> getClass is that subclasses instances can
> equal superclass instances. The writer of the subclass
> decides whether this is possible based on whether or not
> he or she overrides the canEqual method.

Is it not the case, however, that if the subclass overrides equals() and doesn't override canEqual() to return {that instance of this}, we are back in non-compliance territory.

The only benefit I see to this is that the subclass controls the behavior instead of the superclass. That's better but it doesn't address the fundamental issue of designing a part of a system using the equals() method as defined in my base class. If I depend on equals to determine if two points have the same x,y coordinates (e.g. use collections naively) canEquals() solves nothing.