What is heap pollution in Java generics, and how does it lead to a ClassCastException far from its cause?

## First, the vocabulary **Generics** are Java's way of writing code parameterized by a type. `List<String>` means "a list whose elements are Strings"; `String` is the *type argument* and `List<E>` is the *generic type* with *type parameter* `E`. **Type erasure** is the implementation strategy Java uses for generics. The compiler checks your generic types at compile time, then *erases* the type arguments before producing bytecode. At runtime there is just `List` — the `<String>` is gone. The JVM never stores the element type. This was done so generics could be added to Java 5 without breaking older code or the JVM. Because the element type is erased, the runtime cannot verify that a `List<String>` only contains Strings. It simply trusts the compile-time checks. **A raw type** is a generic type used without its type argument: just `List` instead of `List<String>`. Raw types exist for backward compatibility with pre-generics code. Using one turns off generic type checking for that reference. ## What heap pollution is Heap pollution is the situation where **a variable of a parameterized type points to an object that does not match that parameterization** — for example, a reference declared `List<String>` that actually contains an `Integer`. The "heap" is where Java objects live; it is "polluted" because an object on the heap is being viewed through a lying type. It is possible precisely because erasure removes the runtime check. The compiler will *warn* you (an "unchecked" warning) at the spot where the unsafe thing happens, but it still compiles, because such code was sometimes necessary for interoperability. ## How it produces a delayed ClassCastException Consider: ```java List<String> ls = new ArrayList<>(); List raw = ls; // raw type — unchecked, but allowed raw.add(42); // unchecked warning: we just put an Integer in a List<String> String s = ls.get(0); // ClassCastException HERE ``` Nothing throws on `raw.add(42)` — at runtime both are just `ArrayList`, and `Integer` is a valid Object. The pollution happens silently. The failure only appears at `ls.get(0)`: the compiler, knowing `ls` is `List<String>`, inserted a hidden `(String)` cast on the returned value. That cast meets an `Integer` and throws. The stack trace points at the innocent read site, not at `raw.add(42)` where the real mistake was. This *distance* between cause and symptom is what makes heap pollution dangerous. ## Common causes 1. **Mixing raw and parameterized types** (the example above). 2. **Unchecked casts** — `(List<String>) someObject` where the compiler cannot verify the element type. 3. **Generic varargs** — a method like `void f(List<String>... lists)` creates an array of a non-reifiable type internally, which can leak and be polluted (a separate, related topic). ## How to avoid it - Never use raw types in new code. - Treat "unchecked" warnings as real bugs; fix them rather than blanket-suppress them. - Use `@SuppressWarnings("unchecked")` only on the narrowest scope, with a comment proving the operation is actually safe. In short: erasure trades a runtime type guarantee for backward compatibility, and heap pollution is the gap that trade-off leaves open.