جنریک‌ها و سیستم نوعGenerics & the Type System

Let's be honest from the start: generics are one of those parts of Java everyone thinks they know, right up until an interviewer asks "why can't you add to a List<? extends Number>?" and the mind goes blank. The whole subject actually pivots on a single design decision, and once you truly understand that one decision, the rest of the questions topple like dominoes. Let's dig into that one decision together.

Part 0 — a few words you must feel

Before we begin, plant three words in your head with a simple analogy so we can move faster later.

• type safety: the guarantee that a wrong-typed value (an integer) never lands in a string container — and it's the compiler that gives this guarantee, not hope and prayer.
• erasure: removing generic type information when code is compiled to bytecode, for compatibility with old code.
• reified: means "its information is actually present at runtime." Generics are not reified; they're erased.

Mental model: generics are a compile-time contract

Generics in Java exist for exactly one purpose: to move type errors from runtime to compile time. That is, instead of your program blowing up in the user's face, you catch the error the moment you write the code.

Before Java 5 you were forced to write:

List list = ...;
String s = (String) list.get(0);   // you hoped it really was a String

That (String) is a cast — you're telling the compiler "trust me, this is a string." But if you were wrong, you only found out at runtime with a ClassCastException. Generics replaced "trust me" with "prove it": the compiler itself proves the cast is safe, then erases the type info so the bytecode is (almost) identical to the pre-generics version. That single decision — erasure for backward compatibility — explains nearly every "why can't I do X" question about generics.

Generic classes and methods

A generic class parameterizes over one or more type variables:

public class Box<T> {
    private T value;
    public void set(T value) { this.value = value; }
    public T get() { return value; }
}

Box<String> b = new Box<>();   // the diamond operator infers <String>
b.set("hi");
String s = b.get();            // no cast needed

That empty <> on the right is the diamond operator; because you already said Box<String> on the left, the compiler fills it in and you don't repeat String.

Now notice: a generic method can declare its own type parameters, independent of any class parameters. The key syntactic point is that <T> goes before the return type:

public static <T> List<T> singletonList(T item) {
    List<T> list = new ArrayList<>();
    list.add(item);
    return list;
}

// Usually inferred, but you can supply it explicitly:
List<String> xs = Collections.<String>emptyList();

Naming convention (readability only, nothing enforces it): single uppercase letters — T (type), E (element), K/V (key/value), R (result), N (number).

Bounded type parameters

An upper bound restricts a type variable to subtypes of some type, and simultaneously grants you access to that type's members:

// T must be Comparable with itself, so we can call compareTo
public static <T extends Comparable<T>> T max(List<T> list) {
    T best = list.get(0);
    for (T x : list)
        if (x.compareTo(best) > 0) best = x;
    return best;
}

Without extends Comparable<T>, the compiler wouldn't let you write x.compareTo(best) — a bare T isn't known to even have a compareTo. So a bound does two things at once: it restricts and it empowers.

You can have multiple bounds with &. The rule: a class bound (if any) must come first, then interfaces:

<T extends Number & Comparable<T>> // T is a Number AND Comparable

Wildcards and the golden PECS rule

First, a word: a wildcard is ?, an unknown type — meaning "I don't know exactly which type, but it is one specific type."

But why do we even need such a thing? Because generics are invariant. "Invariant" means the subtype relationship of the elements does not carry over to the containers: List<String> is not a List<Object>, even though String is an Object.

If there were no invariance, this would be possible:

List<String> strings = new ArrayList<>();
List<Object> objects = strings;   // ILLEGAL — and here's why
objects.add(42);                  // would put an Integer into a List<String>
String s = strings.get(0);        // ClassCastException at runtime

Wildcards restore some of that flexibility, but safely:

• List<? extends Number> — a list of some unknown subtype of Number. You can read Numbers out, but you cannot add anything (except null), because the compiler doesn't know the exact element type.
• List<? super Integer> — a list of some unknown supertype of Integer. You can add Integers (and its subtypes), but reads come out as Object.

Now the golden mnemonic they ask in every interview, PECS — Producer Extends, Consumer Super:

// src PRODUCES T's -> ? extends T ; dst CONSUMES T's -> ? super T
public static <T> void copy(List<? extends T> src, List<? super T> dst) {
    for (T t : src) dst.add(t);
}

List<Integer> ints = List.of(1, 2, 3);
List<Number> nums  = new ArrayList<>();
copy(ints, nums);   // reads Integers, writes into a List<Number> — safe

And the question that floors everyone: why can't you add to a ? extends? Because List<? extends Number> might in reality be a List<Long>. If the compiler let you add(3) (an Integer), you'd corrupt a List<Long>. The only value guaranteed compatible with every possible ? extends Number is null — because null can be any reference type.

An unbounded wildcard, List<?>, means "list of some unknown thing." Use it when the method logic doesn't depend on the element type at all (e.g. list.size(), list.clear()).

Capture

This is why you'll occasionally see errors like "required: CAP#1, found: Object." The trouble is the compiler won't guarantee that "Mr. X" is the same person across two different calls. The classic fix is a private generic helper method that captures the wildcard into a named type:

public static void swapFirstTwo(List<?> list) {
    swapHelper(list);   // capture the wildcard into a named type
}
private static <T> void swapHelper(List<T> list) {
    T tmp = list.get(0);
    list.set(0, list.get(1));
    list.set(1, tmp);        // now legal: the element type has a name, T
}

Type erasure and everything it forbids

Here is the heart of the chapter. Let's see exactly what the compiler does: it replaces each type variable with its leftmost bound (or Object if unbounded), inserts the necessary casts, and generates bridge methods where needed. The generic type information survives only in .class metadata (Signature attributes) for reflection (inspecting code at runtime) — not in the runtime type checks.

So our Box<T> effectively becomes, after erasure:

public class Box {
    private Object value;
    public void set(Object value) { this.value = value; }
    public Object get() { return value; }
}

And the caller's String s = b.get(); gets a compiler-inserted (String) cast. Now let's walk through the six practical consequences of this erasure, one by one; these are precisely the interview "why can't I" questions.

1. No new T[] and no new T(). The runtime doesn't know what T is, so it can't allocate memory for it. Idiomatic workarounds:

@SuppressWarnings("unchecked")
T[] arr = (T[]) new Object[n];        // unchecked, but the standard trick
T[] arr2 = (T[]) Array.newInstance(clazz, n);  // if you carry a Class<T> token

2. No x instanceof T and no T.class. These need reified type info that doesn't exist. You can write x instanceof List<?> (unbounded wildcard) but not x instanceof List<String> — the latter is a compile error.

3. One class object for all parameterizations.

List<String> a = new ArrayList<>();
List<Integer> b = new ArrayList<>();
System.out.println(a.getClass() == b.getClass());  // true

4. You cannot overload on erasure-equal signatures. These two clash because both erase to foo(List):

void foo(List<String> a) {}
void foo(List<Integer> a) {}   // COMPILE ERROR: name clash, same erasure

5. Static members can't use the class's type parameter. There's one static field shared across all parameterizations; since there's only one runtime class, T is meaningless there.

6. Generic exceptions. You can't catch (T e), and a generic class can't extend Throwable — because catch dispatches on the runtime type, which is erased.

Bridge methods

Erasure creates a subtle problem for overriding. Consider:

class StringBox implements Comparable<StringBox> {
    public int compareTo(StringBox o) { return 0; }
}

Comparable<StringBox> erases to raw Comparable, whose method is compareTo(Object). But StringBox only defines compareTo(StringBox). Now polymorphism runs into trouble: if someone calls the method through a Comparable reference, they land on compareTo(Object), which you never defined! To fix this, the compiler synthesizes a bridge method:

// synthetic, generated by the compiler
public int compareTo(Object o) {
    return compareTo((StringBox) o);   // casts and delegates
}

Reifiable types

Remember we said reified means "its information is present at runtime"? A type is reifiable if its full information is available at runtime. These are reifiable: primitives (like int), non-generic types, raw types (List), unbounded wildcards (List<?>), and arrays of reifiable types.

But parameterized types like List<String> are not reifiable — because that inner String is erased. This is precisely why array creation of a non-reifiable type — new List<String>[10] — is a compile error, and why varargs of a generic type produce the @SafeVarargs / "unchecked generic array creation" warning.

Arrays are covariant; generics are invariant

Arrays remember their component type at runtime and are covariant — meaning the inheritance relationship carries over: String[] is a Object[]. This is a known hole in the type system, patched with a runtime check:

Object[] arr = new String[3];   // legal: covariance
arr[0] = 42;                     // compiles fine...
// throws ArrayStoreException at runtime

Generics deliberately chose the opposite tradeoff — invariance enforced at compile time — precisely so as not to push errors like ArrayStoreException to runtime. This clash of philosophies is why mixing arrays and generics is discouraged. new T[] is banned, and:

List<String>[] lists = new List<String>[10];  // COMPILE ERROR
// If allowed, covariance + erasure would let you store a List<Integer>
// through an Object[] alias and read it back as List<String> unchecked.

Recursive generic bounds (F-bounded polymorphism)

The declaration Enum<E extends Enum<E>> looks circular and meaningless at first glance, but it's actually very precise: it says "E is an enum whose comparison and identity operate on E itself."

This self-referential or F-bounded pattern makes methods return the concrete subtype, not the base:

// Fluent builder that returns the concrete subtype, not the base
abstract class Builder<T extends Builder<T>> {
    protected abstract T self();
    private final List<String> parts = new ArrayList<>();
    public T add(String p) { parts.add(p); return self(); }
}

class HtmlBuilder extends Builder<HtmlBuilder> {
    protected HtmlBuilder self() { return this; }
    public String build() { return "<html>"; }
}

new HtmlBuilder().add("a").add("b").build();  // add() returns HtmlBuilder, so build() is visible

If add returned the base type Builder, then after .add("a") you'd no longer see build() because build only exists on HtmlBuilder. The self-reference solves this. The JDK uses the same shape in Comparable<T> bounds and Enum.

Type inference

Good news: modern Java infers most type arguments for you, so you type less.

• Diamond, new HashMap<>() — infers from the assignment target (Java 7+).
• Method type inference — from argument and target types. (Java 8's improved target typing lets Collections.emptyList() infer correctly inside List<String> x = Collections.emptyList();.)
• var (Java 10+) — infers the variable's static type from the initializer. var list = new ArrayList<String>(); gives list type ArrayList<String>.

Inference is really a constraint-solving process — the compiler collects a set of equations about the types and looks for a solution that satisfies them all. When it can't find one you get errors like "cannot infer type-variable(s) T." Fix it by supplying an explicit witness (Foo.<String>bar(...)) or an explicit target type.

Common pitfalls and gotchas

Best practices

1. Favor generic types and methods over raw types and casts.
2. Apply PECS: extends for producers, super for consumers, exact type only when a parameter is both.
3. Keep @SuppressWarnings("unchecked") minimal and justified.
4. Prefer lists to arrays; never create generic arrays.
5. Use bounded wildcards to make APIs flexible for callers, but keep return types concrete.
6. Reach for a Class<T> token or Array.newInstance only when erasure genuinely blocks you.

Interview Questions

Now it's time to lock everything in with Q&A. Answer each one yourself first, then read the answer.

List<String> a = new ArrayList<>();
List<Integer> b = new ArrayList<>();
System.out.println(a.getClass() == b.getClass());

public static <T> T firstOrNull(List<T> list) {
    return list.isEmpty() ? null : list.get(0);
}
void bad() { String[] arr = new T[10]; }   // inside some generic method

Senior notes & advanced edge cases

By now you understand the mechanics: erasure, PECS, variance, bridge methods. But what separates a senior from a well-read mid-level engineer is knowing where those mechanics buckle in the real world — inside Jackson, inside the actual JDK signatures, inside the Stream API, inside those bizarre runtime bugs — and how teams work around it. This section is exactly that layer.

The big erasure exception: type info survives in class metadata

The main text told you erasure "wipes out" type info. That's 99% true, but it has one critical back door that the entire microservice ecosystem is built on. Erasure wipes type info from instances, but not from the signatures of class members in .class metadata (the Signature attribute the chapter mentioned). Concretely:

• The type of an object is unknown at runtime: new ArrayList<String>().getClass() yields only ArrayList.
• But a type written into the class code — a field signature, a method parameter, or a generic superclass — is recoverable via reflection.

This is where the super type token trick is born. You can't write List<String>.class, but you can build an anonymous generic subclass and let it "bake" the type into its supertype:

abstract class TypeRef<T> {
    private final Type type;
    protected TypeRef() {
        // getClass() -> our anonymous class; its superclass is TypeRef<List<String>>
        Type sc = getClass().getGenericSuperclass();          // TypeRef<List<String>>
        this.type = ((ParameterizedType) sc).getActualTypeArguments()[0];
    }
    public Type getType() { return type; }
}

// {} means we made an anonymous subclass -> the type is locked into its supertype Signature
TypeRef<List<String>> ref = new TypeRef<List<String>>() {};
System.out.println(ref.getType());   // java.util.List<java.lang.String>

That trailing {} is essential: without it there is no subclass, and getGenericSuperclass() gives you nothing usable. This is exactly what you see in Jackson (TypeReference), Gson (TypeToken), and Spring (ParameterizedTypeReference / ResolvableType):

// Jackson: without this, it can't know the list elements should be User
List<User> users = mapper.readValue(json, new TypeReference<List<User>>() {});

// Spring RestClient / WebClient
List<User> body = restClient.get().uri("/users").retrieve()
        .body(new ParameterizedTypeReference<List<User>>() {});

The diagram shows where type info dies and where it survives (bilingual caption): Where type info dies (instances) vs. survives (class Signature) / کجا نوع می‌میرد و کجا می‌ماند:

flowchart TD
  Src["Source: TypeRef&lt —List&lt —String&gt —&gt —(){}"] --> Comp[javac erasure]
  Comp --> Inst["Instance runtime type<br/>= raw TypeRef (erased)"]
  Comp --> Sig["Class Signature metadata<br/>= TypeRef&lt —List&lt —String&gt —&gt — (kept)"]
  Inst -->|getClass| Lost["List&lt —String&gt —? LOST"]
  Sig -->|getGenericSuperclass| Found["ParameterizedType<br/>List&lt —String&gt — RECOVERED"]
  Found --> Libs["Jackson / Gson / Spring<br/>deserialize correctly"]

Why the JDK writes Comparable<? super T>, not Comparable<T>

In the main text you saw max bounded as <T extends Comparable<T>>. It's simple and correct — but the real JDK doesn't sign it that way. The actual signature of Collections.max is:

public static <T extends Comparable<? super T>> T max(Collection<? extends T> coll)

That ? super T is not an accident; it's a subtle application of PECS to the bound itself. Watch this scenario:

class Animal implements Comparable<Animal> { ... }
class Dog extends Animal { }                 // Dog defines no Comparable of its own

List<Dog> dogs = ...;

Dog is not a Comparable<Dog> — it inherits compareTo from Animal, so Dog is actually a Comparable<Animal>. Now:

• With the naive bound <T extends Comparable<T>>: the compiler wants Dog extends Comparable<Dog>, which doesn't hold → Collections.max(dogs) won't compile.
• With the real bound <T extends Comparable<? super T>>: the compiler accepts Dog extends Comparable<Animal> because Animal is a supertype of Dog → it compiles.

PECS on functional interfaces: why Stream.map looks like that

PECS isn't just for List; it applies spectacularly to the functional-interface signatures in the Stream API. The real signature of map:

<R> Stream<R> map(Function<? super T, ? extends R> mapper)

Both wildcards are deliberate and come straight from PECS:

• ? super T on the function's input — a Function is a consumer of T (it takes a T). By Consumer-Super, if you have a Function<Object, R>, you should be able to map it over a Stream<String>. ? super T allows exactly that.
• ? extends R on the function's output — a Function is a producer of R (it returns an R). By Producer-Extends, if your function returns Integer, you should be able to build a Stream<Number>.

The same shape is everywhere in the JDK: Consumer<? super T> in forEach, Supplier<? extends T> in Optional.or, Predicate<? super T> in filter. Mnemonic: a function's input parameter = consume = super; a function's result = produce = extends. The reason stream.map(Object::toString) works over any stream is precisely that ? super T — and good library code sprinkles wildcards generously onto parameters.

Heap pollution mechanically: where does the cast actually blow up?

The main text named heap pollution, but the senior point is understanding how it happens and where it detonates. Precise definition: heap pollution is when a variable of a parameterized type points to an object that isn't of that type — e.g. a List<String> that actually holds an Integer. Erasure keeps this hidden right up until you read.

List<String> strings = new ArrayList<>();
List raw = strings;          // raw type: unchecked warning
raw.add(42);                 // heap pollution! an Integer into a List<String>
String s = strings.get(0);   // <-- ClassCastException is thrown HERE

The second way to inject pollution is generic varargs — which leads us straight to @SafeVarargs.

The precise @SafeVarargs rules and the Java 9 change

Any method that takes a generic varargs parameter (T... args) builds a T[] behind the scenes — and since arrays of a non-reifiable type are forbidden, the compiler emits an "unchecked generic array creation" warning. @SafeVarargs silences it, but it's a promise you must uphold yourself: "I won't write into that array, and I won't leak its reference out."

@SafeVarargs
static <T> List<T> listOf(T... items) {   // we only read -> safe
    return new ArrayList<>(Arrays.asList(items));
}

// An UNSAFE example — why @SafeVarargs is a promise, not a compiler guarantee:
@SafeVarargs
static <T> T[] dangerous(T... items) {
    Object[] arr = items;
    arr[0] = "boom";          // heap pollution if T is, say, Integer
    return items;
}

A senior-grade generic pattern: the typesafe heterogeneous container

Sometimes you want a map whose keys hold different types, with each value guaranteed to match its key's type. The typesafe heterogeneous container trick: instead of parameterizing the container, parameterize the key — use Class<T> as a type token:

public class Favorites {
    private final Map<Class<?>, Object> map = new HashMap<>();

    public <T> void put(Class<T> type, T instance) {
        map.put(Objects.requireNonNull(type), type.cast(instance)); // defensive cast
    }
    public <T> T get(Class<T> type) {
        return type.cast(map.get(type));   // dynamic cast -> runtime safety
    }
}

Favorites f = new Favorites();
f.put(String.class, "hello");
f.put(Integer.class, 42);
String s = f.get(String.class);   // no cast, fully typesafe

The performance cost of erasure, IntStream, and Project Valhalla

Erasure isn't just an academic topic; it has a real performance cost. Because T is Object at runtime, generics cannot hold primitives — there is no List<int>, only List<Integer>. Every number gets boxed: a separate heap object, with memory overhead, garbage-collector pressure, and lost cache locality.

Production traps and a few modern-Java updates

class Box<T> {
    T val;
    <U> U identity(U u) { return u; }   // U is fully independent of T
}
Box raw = new Box();
Number n = raw.identity(42);   // COMPILE ERROR! the return erased to Object

A few updates a 2026 senior should recognize:

• Diamond with anonymous classes (Java 9+). Before Java 9, new Box<>() {} (diamond + anonymous class body) was illegal and you had to spell the type out. Since Java 9 it's allowed when the inferred type is "denotable."
• Type annotations (JSR 308, Java 8+). You can now annotate type arguments themselves: List<@NonNull String>. Tools like the Checker Framework use this for compile-time null checking — a layer beyond generics themselves.
• Intersection-type casts. You can cast a lambda to two types at once to give it both behavior and a marker: (Runnable & Serializable) () -> {}. This produces a serializable lambda with no named class.

Senior-level interview questions

class Box<T> {
    <U> U identity(U u) { return u; }   // U independent of T
}
Box raw = new Box();          // raw type
Number n = raw.identity(42);  // COMPILE ERROR: return is Object

class Favorites {
    private final Map<Class<?>, Object> map = new HashMap<>();
    public <T> void put(Class<T> type, T value) { map.put(type, type.cast(value)); }
    public <T> T get(Class<T> type) { return type.cast(map.get(type)); }
}