Generics

Generics exist only at compile time: the compiler erases each type parameter to its bound, or to Object when unbounded, and inserts the casts. So at runtime List<String> and List<Integer> are the identical raw List with no element-type info retained. This forbids new T(), primitive arguments like List<int>, and any runtime check of a generic type such as instanceof List<String>.

A generic method declares its own <T> before the return type, and the compiler infers it fresh on each call. Its class need not be generic at all — that is why Collections.emptyList() works as a static. A class's <T> is bound once per instance, and a static method can never use it.

A raw List is the generic type used with no type argument — a pre-generics leftover. The compiler turns generic checking off for it, so you may add anything and it still compiles, with only an unchecked warning. List<Object> stays fully checked and holds any object. List<?> is checked too, but its element type is unknown, so you may add nothing but null.

An upper bound lets the compiler call the bounded type's members on T; without it T is only an Object, and it erases to the bound instead of Object. Multiple bounds use & with the class first. A bound constrains what may substitute for T — it is not a runtime check, and only a wildcard, never a type parameter, has a super bound.

List<?> is an unbounded wildcard — the element type is unknown, so you may read elements only as Object and add nothing but null. List<? extends T> is an upper-bounded producer: you read elements as T, yet still cannot add any except null, since the exact subtype is unknown. List<? super T> is a lower-bounded consumer: you may add a T or its subtypes, but reads come back only as Object.

Heap pollution is a variable of a parameterized type pointing at an object that is not of that type — a List<String> reference actually holding an Integer. Erasure lets it through: the cast is unchecked, so the bad value only surfaces later, at the implicit cast on a read, far from its cause. Generic varargs are the classic source: foo(List<String>... lists) compiles to a reified List[] that array covariance lets you pollute.

PECS — producer-extends, consumer-super. A parameter that only produces T values for you to read is declared ? extends T; one that only consumes T values you write into it is declared ? super T; one that does both takes a plain T. Reads from ? extends T are safe because every element is at least a T; writes into ? super T are safe because a T fits any supertype container.

Arrays are reified while generics are erased. An array keeps its component type at runtime and checks every store against it, but new T[10] would erase to new Object[10], so it would police stores against Object and its declared type would be a lie. The compiler therefore rejects generic array creation. Work around it with (T[]) new Object[10] and an unchecked warning, with Array.newInstance and a Class<T> token, or with a List<T>.

No. A class's <T> is bound per instance, while a static member belongs to the class itself — and after erasure one Box class stands behind both Box<String> and Box<Integer>, so a static context has no T to mean. static T value; and static T get() are compile errors. A static method may declare its own parameter instead, inferred per call — which is how Collections.emptyList() works.