Page History

Generically typed code can be freely used with raw types when attempting to preserve compatibility between non-generic nongeneric legacy code and newer generic code. Using raw types with generic code causes most Java compilers to issue "unchecked" warnings but still compile the code. When generic and non-generic nongeneric types are used together correctly, these warnings can be ignored; at other times, these warnings can denote potentially unsafe operations.

According to the _Java Language Specification_ \[[JLS 2005|AA. Bibliography#JLS 05]\], [§4.8, "Raw Types,"|http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.8] \[[JLS 2005|AA. Bibliography#JLS 05]\]:

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 When a parameterized type tries to access an object that is not of the parameterized type, heap pollution occurs. For instance, consider the following code snippet below.

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

It is insufficient to rely on unchecked warnings alone to detect violations of this rule. According to the _Java JLS \[[JLS 2005|AA. Bibliography#JLS 05]\], Language Specification_, [§4.12.2.1, "Heap Pollution," |http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#111088] \[[JLS 2005|AA. Bibliography#JLS 05]\]:

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.

Wiki MarkupExtending legacy classes and generifying making the overriding methods generic fails because this is disallowed by the _Java Language Specification_ \[[JLS 2005|AA. Bibliography#JLS 05]\].

Noncompliant Code Example

This noncompliant code example compiles although it but produces an unchecked warning because the raw type of the List.add() method is used (the list parameter in the addToList() method) rather than the parameterized type.

class MixedTypes {
  private static void addToList(List list, Object obj) {
    list.add(obj); // unchecked warning
  }

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

When executed, this code produces throws an exception. This happens not because a List<String> receives an Integer but because the value returned by list.get(0) is an improper type (an Integer rather than a String). In other words, the code throws an exception some time after the execution of the operation that actually caused the exceptionerror, complicating debugging.

...

This compliant solution enforces type safety by changing the addToList() method signature to enforce proper type checking. It also complies by adding a String rather than an Integer.

class Parameterized {
  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, "1");
    System.out.println(list.get(0));
  }
}

The compiler does not allow prevents insertion of an Object once list is parameterized. Likewise, to the parameterized list because addToList() cannot be called with an argument whose type produces a mismatchwith an argument whose type produces a mismatch. This code has consequently been changed to add a String to the list instead of an Integer.

Compliant Solution (Legacy Code)

While the previous compliant solution eliminates use of raw collections, this could it may be infeasible to implement this solution when interoperating with legacy code.

...

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

...

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

...

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 following output:

...

This compliant solution generifies the addToList() method, which eliminates eliminating any possible type violations.

...

If the method addToList() is externally defined (such as in a library or as 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 nongeneric code.

Exceptions

*OBJ03-EX0* Raw types must be used in class literals. For example, because {{List<Integer>.class}} is illegalinvalid, it is permissible to use the raw type {{List.class}} \[[Bloch 2008|AA. Bibliography#Bloch 08]\].

...

Risk Assessment

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

...

...