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 2015].)

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 Generically typed code can be freely used with raw types when attempting to preserve compatibility between non-generic 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.

When generic and nongeneric . However, using raw types with generic code causes most Java compilers to issue "unchecked" warnings. When generic and non-generic types are used together correctly, these warnings are not catastrophic, but can be ignored; at other times, these warnings may can denote potentially unsafe operations. If generic and non-generic code must be used together, these warnings should not be simply ignored.

According to the Java Language Specification [JLS 2005], Section 4.8, "Raw Types"

The use of raw types is allowed only as a concession to compatibility of legacy code. The use of raw types in code written after the introduction of genericity into the Java programming language is strongly discouraged. It is possible that future versions of the Java programming language will disallow the use of raw types.

If a parameterized type tries to access an object that is not of the parameterized type, heap pollution results. For instance, consider the code snippet below.

Mixing generic and raw types is allowed provided that heap pollution does not occur. For example, consider the following code snippet.

List list

List l = new ArrayList<Integer>ArrayList();
List<String> ls = llist; // Produces unchecked warning

It is insufficient to rely on unchecked warnings alone to detect violations of this guidelineIn some cases, it is possible that a compile-time unchecked warning will not be generated. According to the Java Language Specification [ JLS 2005], Section 4§4.12.2.1, "Heap Pollution"

Wiki Markup
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 suppressed _\[sic\]_. This practice is unhealthy at best.

 "Variables of Reference Type" [JLS 2015]:

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.

Heap pollution can also occur if the program aliases an array variable of non-reifiable element type through an array variable of a supertype that is either raw or nongeneric. Extending legacy classes and generifying the overriding methods is not a panacea as this is made illegal by the Java Language Specification [JLS 2005]. It is best to avoid mixing generic and non-generic code.

Noncompliant Code Example

This noncompliant code example compiles but results in heap pollution. The compiler produces an unchecked warning because the raw type of the List.add() method is used a raw argument (the list obj parameter in the addToList() method) instead of the parameterized type. To make this code compile cleanly, the @SuppressWarnings annotation is used. is passed to the List.add() method. 

public class MixedTypesListUtility {
  @SuppressWarnings("unchecked")
  private static void addToList(List list, Object obj) {
    list.add(obj); // Unchecked warning
  }

  privatepublic static void printmain(String[] args) {
    List<String> list = new ArrayList<String> ();
    addToList(list, 142);
    System.out.println(list.get(0));
  }
//  public static void main(String[] args) {Throws ClassCastException
    MixedTypes.print();
  }
}

When executed, this code produces an exception because the value returned by list.get(0) is not of the proper type, that is, String:

Exception in thread "main" java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String
	at Raw.print(Test.java:11)
	at Raw.main(Test.java:14)

Compliant Solution

By gleaning information from the diagnostic exception message, the error can be quickly traced to the line addToList(1) in the noncompliant code example. Changing this to addToList("1") is a superficial defense. To resolve the issue, use parameterized types consistently.

Heap pollution is possible in this case because the parameterized type information is discarded before execution. The call to addToList(list, 42) succeeds in adding an integer to list, although it is of type List<String>. This Java runtime does not throw a ClassCastException until the value is read and has an invalid type (an int rather than a String). In other words, the code throws an exception some time after the execution of the operation that actually caused the error, complicating debugging.

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).

Compliant Solution (Parameterized Collection)

This compliant solution enforces type safety by changing the addToList() method signature to enforce proper type checking:To enforce compile time checking of types, replace the parameters to the method addToList() with List<String> list and String str.

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

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

The compiler prevents insertion of an 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 instead of an int to the list.

Compliant Solution (Legacy Code)

The previous compliant solution eliminates use of raw collections, but implementing this solution when interoperating with legacy code may be infeasible.

Suppose that the addToList() method is legacy code that cannot be changed. The following compliant solution creates a checked view of the list by using the Collections.checkedList() method. This method returns a wrapper collection that performs runtime type checking in its implementation of the add() method before delegating to the back-end List<String>. The wrapper collection can be safely passed to the legacy addToList() method.

class ListUtility {
  private static void addToList(List list, Object obj) {
    list.add(obj); // Unchecked warning, also throws ClassCastException
  }

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

The compiler does not allow insertion of an Object once list is parameterized. Likewise, addToList() cannot be called with an argument whose type produces a mismatchstill issues the unchecked warning, which may still be ignored. However, the code now fails when it attempts to add the integer to the list, consequently preventing the program from proceeding with invalid data.

Noncompliant Code Example

This noncompliant code example compiles and runs cleanly because it suppresses the unchecked warning produced by the raw List. The method printOneadd() method. The printNum() method intends to print the value one42, either as an int or as a double depending on the type of the variable type.

class BadListAdderListAdder {
  @SuppressWarnings("unchecked")
  private static void addToList(List list, Object obj) {
    list.add(obj);     // Unchecked warning suppressed
  }

  private static <T> void printOneprintNum(T type) {
    if (!(type instanceof Integer || type instanceof Double)) {
      System.out.println("Cannot print in the supplied type");
    }
    List<T> list = new ArrayList<T>();
    addToList(list, 142);
    System.out.println(list.get(0));
  }

  public static void main(String[] args) {
    double d = 142;
    int i = 142;
    System.out.println(d); 
    BadListAdderListAdder.printOneprintNum(d);
    System.out.println(i);
    BadListAdderListAdder.printOneprintNum(i);
  }
}

However, despite list being correctly parameterized, this method prints '1' 42 and never '142.0 ' because the int value '1' 42 is always added to list without being type checked. This code produces the following output:

142.0 
1  42
142
1
42

Compliant

...

Solution (Parameterized Collection)

This compliant solution generifies the addToList() method to eliminate , eliminating any possible type violations.:

class GoodListAdderListAdder {
  private static <T> void addToList(List<Integer>List<T> list, IntegerT it) {
    list.add(it);
  }

  private static// voidNo addToList(List<Double> list, Double d) {
    list.add(d);warning generated
  }

  private static <T> void printOneprintNum(T type) {
    if (type instanceof Integer) {
      List<Integer> list = new ArrayList<Integer>();
      addToList(list, 142);
      System.out.println(list.get(0));
    }
    else if (type instanceof Double) {
      List<Double> list = new ArrayList<Double>();

      // This will not compile if addToList(list, 142.0); is used
// Will not compile with  addToList(list, 142 instead of 42.0);

      System.out.println(list.get(0));
    }
    else {
      System.out.println("Cannot print in the supplied type");
    }
  }

  public static void main(String[] args) {
    double d = 142;
    int i = 142;
    System.out.println(d);
    GoodListAdderListAdder.printOneprintNum(d);
    System.out.println(i);
    GoodListAdderListAdder.printOneprintNum(i);
  }
}

This code compiles cleanly and runs as expected by printingproduces the correct output:

142.0
142.0
142
1
42

If the method addToList() is externally defined (such as in a library or is as an upcall method) and cannot be changed, the same compliant method printOneprintNum() can be used, but no warnings result if addToList(1list, 42) is used instead of addToList(1list, 42.0). Great care must be taken to ensure type safety when generics are mixed with non-generic nongeneric code.

Exceptions

MSC00-EX1: Raw types must be used in class literals. For example, as List<Integer>.class is illegal, it is permissible to use the raw type List.class [Bloch 2008].

MSC00-EX2: The instanceof operator cannot be used with generic types. It is permissible to mix generic and raw code in such cases [Bloch 2008].

if(o instanceof Set) { // Raw type
  Set<?> m = (Set<?>) o; // Wildcard type 
  // ...
}

Risk Assessment

Noncompliant Code Example (Variadic Arguments)

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>.

class ListModifierExample {
  public static void modify(List<String>... list) {
    Object[] objectArray = list;
    objectArray[1] = Arrays.asList(42);   // Pollutes list, no warning

    for (List<String> ls : list) {
      for (String string : ls) {          // ClassCastException on 42
        System.out.println(string);
      }
    }
  }
 
  public static void main(String[] args) {
    List<String> s = Arrays.asList("foo", "bar");
    List<String> s2 = Arrays.asList("baz", "quux");
    modify( s, s2);                       // Unchecked varargs warning
  }
}

This program produces the following output:

foo
bar
Exception in thread "main" java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String
	at ListModifierExample.modify(Java.java:13)
	at ListModifierExample.main(Java.java:25)
	at Java.main(Java.java:33)

Noncompliant Code Example (Array of Lists of Strings)

This noncompliant code example is similar, but it uses an explicit array of lists of strings as the single parameter to modify(). The program again dies with a ClassCastException from the integer 42 injected into a list of strings.

class ListModifierExample {
  public static void modify(List<String>[] list) {
    Object[] objectArray = list;          // Valid
    objectArray[1] = Arrays.asList(42);   // Pollutes list, no warning

    for (List<String> ls : list) {
      for (String string : ls) {          // ClassCastException on 42
        System.out.println(string);
      }
    }
  }
 
  public static void main(String[] args) {
    List<String> s = Arrays.asList("foo", "bar");
    List<String> s2 = Arrays.asList("baz", "quux");
    List list[] = {s, s2};
    modify(list);                         // Unchecked conversion warning
  }
}

Compliant Solution (List of Lists of Strings)

This compliant solution uses a list of lists of strings as the argument to modify(). This type safety enables the compiler to prevent the modify() method from injecting an integer into the list. In order to compile, the modify() method instead inserts a string, preventing heap pollution.

class ListModifierExample {
  public static void modify(List<List<String>> list) {
    list.set( 1, Arrays.asList("forty-two")); // No warning

    for (List<String> ls : list) {
      for (String string : ls) {            // ClassCastException on 42
        System.out.println(string);
      }
    }
  }
 
  public static void main(String[] args) {
    List<String> s = Arrays.asList("foo", "bar");
    List<String> s2 = Arrays.asList("baz", "quux");
    List<List<String>> list = new ArrayList<List<String>>();
    list.add(s);
    list.add(s2);
    modify(list);
  }
}

Note that to avoid warnings, we cannot use Arrays.asList() to build a list of lists of strings because that method is also variadic and would produce a warning about variadic arguments being parameterized class objects.

Risk Assessment

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

Automated Detection

...

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this guideline on the CERT website.

Bibliography

\[[Langer 2008|AA. Bibliography#Langer 08]\] Topic 3, "[Coping with Legacy|http://www.angelikalanger.com/GenericsFAQ/FAQSections/ProgrammingIdioms.html#Topic3]"
[[Bloch 2008|AA. Bibliography#Bloch 08]\] Item 23: "Don't use raw types in new code"
[[Bloch 2007|AA. Bibliography#Bloch 07]\] Generics, 1. "Avoid Raw Types in New Code"
\[[Naftalin 2006b|AA. Bibliography#Naftalin 06b]\] "Principle of Indecent Exposure"
[[JLS 2005|AA. Bibliography#JLS 05]\] 4.8 "Raw types" and 5.1.9 "Unchecked Conversion"

Tool	Version	Checker	Description
Parasoft Jtest	Include Page Parasoft_V Parasoft_V	CERT.OBJ03.AGBPT	Avoid conversions from parameterized types to raw types

Bibliography

...

Image Added Image Added Image Added49. Miscellaneous (MSC)      49. Miscellaneous (MSC)      MSC01-J. Do not use insecure or weak cryptographic algorithms