60 @Override public boolean equals(Object o) {
61 if (o == this) {
62 return true;
63 } else if (!(o instanceof Map.Entry)) { 64 return false;
65 }
66 var entry = (Map.Entry<?, ?>) o; 970 public boolean equals(Object o) {
971 if (o == this) {
972 return true;
973 } else if (!(o instanceof Map)) { 974 return false;
975 }
9762989 public boolean equals(Object o) {
2990 if (o == this) {
2991 return true;
2992 } else if (!(o instanceof Map)) {2993 return false;
2994 }
2995This equals method is checking to see if the argument is some incompatible type (i.e., a class that is neither a supertype nor subtype of the class that defines the equals method).
Bad Practice
This class might have an equals method that looks like:
public boolean equals(Object o) {
if (o instanceof Foo)
return name.equals(((Foo)o).name);
else if (o instanceof String) // Foo is not related to String in any way!
return name.equals(o);
else return false;
}
This is considered bad practice, as the equals method will not be symmetric and transitive. Without those properties, very unexpected behaviors are possible, such as the scenario of a equals b AND b equals c IMPLIES a equals c being false.
Recommended
Do not perform checks for unrelated types in the equals method.
Exceptions
In some cases, such as when implementing a comparator for elements of a collection, it may be useful to define an equals method which checks for an entirely different type to allow for greater flexibility. If you have such a requirement, it should be safe to use this pattern to achieve it.
However, do note that while Java's collection APIs use the equals method of the object we are looking for and not that of the objects within the collection, they are not obligated by contract to keep this behavior and could cause problems in a future update.