[Checkers] RFE: Equality checking

[Mahmood Ali]

Hi Mike,

In the framework, I have had some trouble with .equals() usage, as its  
parameter is Object rather than a more specific type.  Especially when  
working with interfaces, .equals() seems to have a inconsistent  
semantics, and that impacts other dependant methods, like  
Collection.contains(), Map.get(), Map.containsKey(), ...

Examples:
__Covariant with respect to arguments:
- Interfaces: Set.equals(Object) and List.equals(Object) return true  
iff the passed set/list contains the same values as the receiver.   
They disregard the actual run-time type of the parameter, so long it  
is a subtype of Set/List.  In other words HashSet.equals(TreeSet) may  
return true.

- Classes: Date.equals() specifies that two dates, d1 and d2, are  
equals iff d1.getTime() == d2.getTime().  Date has three direct  
subtypes: java.sql.Date, Time, and TimeStamp.  Date.equals(Time) and  
java.sql.Date.equals(Time) may return true.  TimeStamp.equals(Time)  
always returns false.  java.sql.TimeStamp documentation starts with  
explaining this behavior.

__ Invariant with respect to arguments:
- Interfaces: CharSequence does not refine Object.equals()  
specification.  String.equals(Name) never returns true, even though  
both String and Name are CharSequence and represent the same value.   
This resulted in errors in Framework.

- Classes: Calendar.equals() and GregoarianCalendar.equals() seems to  
be broken but I cannot confirm it.

I don't know what we can do about it, but I just thought about this  
while talking about 'incorrect equality checking' in the presentation.

Regards,
Mahmood