Was ist Type Erasure, und was kannst du deswegen nicht tun?

Generische Typinformation existiert zur Compile-Zeit und wird im Bytecode gelöscht, dort ist eine List of String nur eine List mit vom Compiler eingefügten Casts. Du kannst also kein instanceof gegen einen parametrisierten Typ prüfen, kein Array eines Typparameters erzeugen und keine zwei Methoden überladen, die sich nur im generischen Argument unterscheiden. Der Compiler fügt Bridge-Methoden ein, damit Polymorphie weiter funktioniert, und ungeprüfte Casts können Heap Pollution verursachen.

Generics sind ein Compile-Zeit-Feature. Nach dem Compilieren ist eine List of String nur noch eine List, mit vom Compiler eingefügten Casts, und genau das hat Generics abwärtskompatibel gehalten. Die sichtbaren Konsequenzen: ich kann nicht fragen, ob etwas eine Instanz eines parametrisierten Typs ist, ich kann kein Array eines Typparameters ohne ungeprüften Cast instanziieren, und ich kann eine Methode nicht auf zwei verschiedene generische Argumente überladen, weil beide zur selben Signatur erodieren. Deshalb ist auch eine Unchecked-Cast-Warnung ernst zu nehmen: eine falsch typisierte Liste kann das falsche Element halten und später an irgendeinem unbeteiligten Cast scheitern, das ist Heap Pollution und wirklich lästig aufzuspüren. Wenn ich eine API entwerfe, nutze ich Bounded Wildcards, damit sie benutzbar ist, nach der Regel Producer extends, Consumer super, eine Methode, die aus einer Collection liest, nimmt also einen Wildcard, der den Typ erweitert. Brauche ich den Typ wirklich zur Laufzeit, etwa um einer JSON-Bibliothek zu sagen, wohin sie deserialisieren soll, übergebe ich ein Class-Objekt oder nutze eine Type Reference, die den Parameter über eine anonyme Unterklasse einfängt, denn das Typargument einer Klasse bleibt in der Signatur erhalten.