MSC00-J. Do not mix generic with non-generic raw types in new code

Generically typed code can be freely used with raw types when attempting to preserve compatibility between non-generic legacy code and newer generic code. 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 at other times, these warnings may 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.

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

It is insufficient to rely on unchecked warnings alone to detect violations of this guideline. According to the Java Language Specification [JLS 2005], Section 4.12.2.1, "Heap Pollution"

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.

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 produces an unchecked warning because the raw type of the List.add() method is used (the list parameter in addToList() method) instead of the parameterized type. To make this code compile cleanly, the @SuppressWarnings annotation is used.

public class MixedTypes {
  @SuppressWarnings("unchecked")
  private static void addToList(List list, Object obj) {
    list.add(obj); // Unchecked warning
  }
  private static void print() {
    List<String> list = new ArrayList<String> ();
    addToList(list, 1);
    System.out.println(list.get(0));
  }
  public static void main(String[] args) {
    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.

To enforce compile time checking of types, replace the parameters to the method addToList() with List<String> list and String str.

class Parameterized {
  private static void addToList(List<String> list, String str) {
    list.add(str);     // Unchecked warning
  }
  private static void print() {
    List<String> list = new ArrayList<String> ();
    addToList(list, "1");
    System.out.println(list.get(0));
  }
  public static void main(String[] args) {
    Parameterized.print();
  }
}

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

Noncompliant Code Example

This noncompliant code example compiles and runs cleanly. The method printOne() intends to print the value one, either as an int or as a double depending on the type of the variable type.

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

  private static <T> void printOne(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, 1);
    System.out.println(list.get(0));
  }

  public static void main(String[] args) {
    double d = 1;
    int i = 1;
    System.out.println(d); 
    BadListAdder.printOne(d);
    System.out.println(i);
    BadListAdder.printOne(i);
  }
}

However, despite list being correctly parameterized, this method prints '1' and never '1.0' because the int value '1' is always added to list without being type checked.

This code produces the output:

1.0 
1  
1
1

Compliant Solution

This compliant solution generifies the addToList() method to eliminate possible type violations.

class GoodListAdder {
  private static void addToList(List<Integer> list, Integer i) {
    list.add(i);
  }

  private static void addToList(List<Double> list, Double d) {
    list.add(d);
  }

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

      // This will not compile if addToList(list, 1) is used
      addToList(list, 1.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 = 1;
    int i = 1;
    System.out.println(d);
    GoodListAdder.printOne(d);
    System.out.println(i);
    GoodListAdder.printOne(i);
  }
}

This code compiles cleanly and runs as expected by printing:

1.0
1.0
1
1

If the method addToList() is externally defined (such as in a library or is an upcall method) and cannot be changed, the same compliant method printOne() can be used, but no warnings result if addToList(1) is used instead of addToList(1.0). Great care must be taken to ensure type safety when generics are mixed with non-generic 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

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 rule on the CERT website.

Bibliography

[[Langer 2008]] Topic 3, "Coping with Legacy"
[[Bloch 2008]] Item 23: "Don't use raw types in new code"
[[Bloch 2007]] Generics, 1. "Avoid Raw Types in New Code"
[[Naftalin 2006b]] "Principle of Indecent Exposure"
[[JLS 2005]] 4.8 "Raw types" and 5.1.9 "Unchecked Conversion"

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