The java.util.Collection
API has methods that accept Object
parameters such as Collection.remove(Object o)
,
and Collection.contains(Object o)
. When the actual type of the object provided to these methods is not consistent with the type declared
on the Collection
instantiation, those methods will always return false
or null
. This is most likely unintended
and hides a design problem.
This rule raises an issue when the type of the argument of the following APIs is unrelated to the type used for the Collection
declaration:
-
Collection.remove(Object o)
-
Collection.removeAll(Collection<?>)
-
Collection.contains(Object o)
-
List.indexOf(Object o)
-
List.lastIndexOf(Object o)
-
Map.containsKey(Object key)
-
Map.containsValue(Object value)
-
Map.get(Object key)
-
Map.getOrDefault(Object key, V defaultValue)
-
Map.remove(Object key)
-
Map.remove(Object key, Object value)
Noncompliant Code Example
public class S2175 {
public static void main(String[] args) {
String foo = "42";
Map<Integer, Object> map = new HashMap<>();
map.remove(foo); // Noncompliant; will return 'null' for sure because 'map' is handling only Integer keys
// ...
List<String> list = new ArrayList<String>();
Integer integer = Integer.valueOf(1);
if (list.contains(integer)) { // Noncompliant; always false.
list.remove(integer); // Noncompliant; list.add(integer) doesn't compile, so this will always return 'false'
}
}
}
See
- CERT, EXP04-J. - Do not pass arguments to certain Java Collections Framework methods
that are a different type than the collection parameter type