Page History

...

According to the Java Language Specification [JLS 2005] section , 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.

...

It is insufficient to rely on unchecked warnings alone to detect violations of this guideline. According to the Java Language Specification [JLS 2005] section , Section 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.

...

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

...

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

...