Page History

Heap pollution occurs when a variable of a parameterized type references an object that is not of that parameterized type. (For more information on heap pollution, see The Java Language Specification (JLS), §4.12.2., "Variables of Reference Type" [JLS 20142015].).

Mixing generically typed code with raw typed code is one common source of heap pollution. Generic types were unavailable prior to Java 5, so popular interfaces such as the Java Collection Framework relied on raw types. Mixing generically typed code with raw typed code allowed developers to preserve compatibility between nongeneric legacy code and newer generic code but also gave rise to heap pollution. Heap pollution can occur if the program performs some operation involving a raw type that would give rise to a compile-time unchecked warning.

...

...

List list = new ArrayList();
List<String> ls = list; // Produces unchecked warning

When generic and nongeneric types are used together correctly, these warnings can be ignored; at other times, these warnings can denote potentially unsafe operations. Mixing generic and raw types is allowed provided that heap pollution does not occur. For  For example, consider the following code snippet. In some cases, it is possible that a compile

List list = new ArrayList();
List<String> ls = list; // Produces unchecked warning

In some cases, it is possible that a compile-time unchecked warning will not be generated. According to the JLS, §4.12.2.1, "Heap Pollution "Variables of Reference Type" [JLS 20052015]:

Note that this does not imply that heap pollution only occurs if an unchecked warning actually occurred. It is possible to run a program where some of the binaries were compiled by a compiler for an older version of the Java programming language, or by a compiler that allows the unchecked warnings to [be] suppressed. This practice is unhealthy at best.

...

Even when heap pollution occurs, the variable is still guaranteed to refer to a subclass or subinterface of the declared type , but is not guaranteed to always refer to a subtype of its declared type. In this example, list does not refer to a subtype of its declared type (List<String>) but only to the subinterface of the declared type (List).

...

This compliant solution enforces type safety by changing the addToList() method signature to enforce proper type checking.:

class ListUtility {
  private static void addToList(List<String> list, String str) {
    list.add(str);     // No warning generated
  }

  public static void main(String[] args) {
    List<String> list = new ArrayList<String> ();
    addToList(list, "42");
    System.out.println(list.get(0));
  }
}

The compiler prevents insertion of an Object object to the parameterized list because addToList() cannot be called with an argument whose type produces a mismatch. This code has consequently been changed to add a String to the list instead of an int to the list.

Compliant Solution (Legacy Code)

...

The compiler still issues the unchecked warning, which may still be ignored. However, the code now fails when it attempts to add the Integer integer to the list, consequently preventing the program from proceeding with invalid data.

...

Heap pollution can occur without using raw types such as java.util.List. This noncompliant code example builds a list of lists of strings before passing it to a modify() method. Because this method is variadic, it casts list into an array of lists of strings. But Java is incapable of representing the types of parameterized arrays. This limitation allows the modify() method to sneak a single integer into the list. Although the Java compiler emits several warnings, this program compiles and runs until it tries to extract the integer 42 from a List<String>.

...

Mixing generic and nongeneric code can produce unexpected results and exceptional conditions.

Automated Detection

Bibliography

...

...