The interfaces of the Java Collections Framework [JCF 2014] use generically typed, parameterized methods, such as add(E e)
and put(K key, V value)
, to insert objects into the collection or map, but they have other methods, such as contains()
, remove()
, or and get()
, that accept an argument of type Object
rather than a parameterized type. Consequently, these methods accept an object of any type. The collections framework interfaces were designed in this manner to maximize backwards compatibility, but this design can also lead to coding errors. Programmers must ensure that arguments passed to methods such as Map<K,V>
get()
, Collection<E>
contains()
, and remove()
have the same type as the parameterized type of the corresponding class instance.
...
Code Block | ||
---|---|---|
| ||
import java.util.HashSet; public class ShortSet { public static void main(String[] args) { HashSet<Short> s = new HashSet<Short>(); for (int i = 0; i < 10; i++) { s.add((short)i); // castCast required so that the code compiles s.remove(i); // triesTries to remove an Integer } System.out.println(s.size()); } } |
...
Code Block | ||
---|---|---|
| ||
import java.util.HashSet; public class ShortSet { public static void main(String[] args) { HashSet<Short> s = new HashSet<Short>(); for (int i = 0; i < 10; i++) { s.add((short)i); // removeRemove a Short if (s.remove((short)i) == false) { System.err.println("Error removing " + i); } } System.out.println(s.size()); } } |
...
EXP04-EX2: Some Java programs, particularly legacy programs, may iterate through a collection of variously typed objects with the expectation that only those objects with the same type as the collection parameter will be operated on. An exception is allowed in cases where there is no expectation that the operation is not a no-op.
...
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
EXP04-J | Low | Probable | Low | P6 | L2 |
Automated Detection
Detection of invocations of Collection.remove()
whose operand fails to match the type of the elements of the underlying collection is straightforward. It is possible, although unlikely, that some of these invocations could be intended. The remainder are heuristically likely to be in error. Automated detection for other APIs could be possible.
Bibliography
Chapter 5 | |||
[JCF 2014] | The Java Collections Framework | [Core Java 2004]Chapter 5 | |
[JLS 2005] | |||
[Seacord 2015] | IDS17-J. Prevent XML External Entity Attacks LiveLesson | ||
The Joy of Sets |
...