Page History

A boxing conversion converts the value of a primitive type to the corresponding value of the reference type. One example is the automatic conversion from int to Integer [JLS 2005]. This is convenient in cases where an object parameter is required, such as with collection classes like Map and List. Another use case is for interoperation with methods that require their parameters to be object references rather than primitive types. Automatic conversion to the resulting wrapper types also reduces clutter in code.

When the reference type causing the boxing conversion is one of the specific numeric wrapper types (for example, Boolean, Byte, Character, Short, Integer, Long, Float, or Double) the resulting type is the reference type and easily predicted. However, autoboxing can produce unexpected results when the reference type causing the boxing conversion is nonspecific (for example, Number or Object) and the value being converted is the result of an expression that mixes primitive numeric types. In this latter case, the specific wrapper type that results from the boxing conversion is chosen on the basis of the numeric promotion rules governing the expression evaluation. Consequently, programs that use primitive arithmetic expressions as actual arguments passed to method parameters that have nonspecific reference types must cast the expression to the intended primitive numeric type before the boxing conversion takes place (unless the intended type is the resulting type of the expression)Certain Generic Types such the Collections Framework interfaces use parameterized methods such as add() or put() to insert objects into the collection, but have other methods such as contains(), equals(), remove(), or get() that accept an argument of type Object rather than of type E allowing a programmer to attempt to remove an object of any type.  The Collections Framework Interfaces were designed in this manner to maximize backwards compatibility, but can also lead to coding errors.  Programmers must ensure that arguments passed to methods such as the Map<K,V> get() method or the Collection<E>  contains(), equals(), or remove() methods have the same type as the parameterized type of the corresponding class instance.

Noncompliant Code Example

After adding then removing 10 elements, the HashSet in this noncompliant code example still contains 10 elements and not the expected 0. Java's type checking requires that only values of type Short can be inserted into s. Consequently, the programmer has added a cast to short so that the code will compile.  However, the Collections<E>.remove() method accepts an argument of type Object rather than of type E. allowing a programmer to attempt to remove an object of any type. In this noncompliant code example, the programmer has neglected to also cast the variable i before passing it to the remove() method which is autoboxed into an object of type Integer rather than one of type Short. The HashSet contains only values of type Short; the code attempts to remove objects of type Integer. Consequently, the remove() method has no effect.

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);
	  s.remove(i); // tries to remove an Integer
	}
	System.out.println(s.size());
  }
}

This noncompliant code example also violates EXP00-J. Do not ignore values returned by methods.

Compliant Solution

Objects removed from a collection must share the type of the elements of the collection. Numeric promotion and autoboxing can produce unexpected object types. This compliant solution uses an explicit cast to short that matches the intended boxed type.

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);
	  // remove a Short
	  if (s.remove((short)i) == false) {
	    System.err.println("Error removing " + i);
	  }
	}
	System.out.println(s.size());
  }
}

Risk Assessment

Allowing autoboxing to produce objects of an unintended type Passing arguments to certain methods that are different than the parameterized type of the class instance can cause silent failures with some APIs, such as the Collections library. These failures can result , resulting in unintended object retention, memory leaks, or incorrect program operation [Techtalk 2007].

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

...