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.
...
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 example, consider the following code snippet. 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.
...
Item 23, "Don't Use Raw Types in New Code" | |||
[Bloch 2007] | |||
Puzzle 88, "Raw Deal" | |||
Section 8.3, "Avoid Casting by Using Generics" | |||
| |||
[ | JLS 2005"Heap Pollution" | ||
§4.8, "Raw Types" | |||
Topic 3, "Coping with Legacy" | |||
Chapter 8, "Effective Generics" | |||
"Principle of Indecent Exposure" | |||
"Create a Checked Collection" | "Heap Pollution | " |
...