[Checkers] RFE: Equality checking
mahmood at MIT.EDU
Sun Oct 19 17:58:05 EDT 2008
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(), ...
__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
- 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.
More information about the checkers