Generics catch real bugs at compile time, but they are not a general-purpose replacement for runtime type information — because of type erasure, a whole category of operations that look reasonable to write simply are not legal. You cannot write new T(), cannot check instanceof List<String>, cannot create new T[10], cannot declare a static T field, and cannot write class MyException<T> extends Exception. None of these are arbitrary rules. Each one is a direct, provable consequence of erasure discarding type arguments before the JVM ever runs the code, and each one has a standard, well-known workaround. This article catalogs the restrictions you will actually run into and the idiom that replaces each one.

What Generics Cannot Do

Every restriction generics impose traces back to one fact: by the time your code runs, the type argument you wrote is gone. Anything that would require the JVM to know a type parameter's actual value at runtime is off the table.

THE RESTRICTIONS, AT A GLANCE:

  new T()                      COMPILE ERROR - cannot instantiate a type variable
  obj instanceof List<String>  COMPILE ERROR - illegal generic type for instanceof
  new T[10]                    COMPILE ERROR - cannot create a generic array
  new List<String>[5]          COMPILE ERROR - cannot create an array of a generic type
  List<int>                    COMPILE ERROR - primitives cannot be type arguments
  static T field                COMPILE ERROR - static context cannot use the class's T
  class Foo<T> extends Exception COMPILE ERROR - a Throwable subtype cannot be generic
  catch (T e) { }               COMPILE ERROR - cannot catch a type variable
  void m(List<String> a)
  void m(List<Integer> a)       COMPILE ERROR - overloads erase to the same signature

EACH HAS A STANDARD WORKAROUND:

  new T()             -> accept a Supplier<T> or a Class<T> token
  instanceof T         -> check the raw type or an unbounded wildcard List<?>
  new T[10]            -> accept a Class<T> token and use Array.newInstance()
  List<int>            -> use the wrapper type List<Integer> (autoboxing handles the rest)
  static T field       -> give the static member its OWN type parameter <U>
  class Foo<T> extends Exception -> keep the exception non-generic; carry T as a field

Basic Overview - Why Each Restriction Exists

1. YOU CANNOT INSTANTIATE OR REFLECT ON A TYPE PARAMETER DIRECTLY

   Fresher view  : new T() looks like it should work the same way
                   new String() does - but T isn't a real class name
                   to the JVM by the time the program runs.

   Deeper view   : erasure replaces T with its bound (usually Object)
                   in the compiled class. "new T()" would compile to
                   "new Object()" - clearly not what any caller
                   intended, and the compiler refuses to guess. The
                   fix is always to hand the missing information in
                   explicitly, either as a Supplier<T> factory or a
                   Class<T> token used with reflection.

2. YOU CANNOT ASK THE JVM "IS THIS SPECIFICALLY A List<String>?"

   Fresher view  : instanceof and casts only ever check the raw,
                   erased type at runtime - List, not List<String>.

   Deeper view   : since List<String> and List<Integer> share one
                   Class object, there is nothing distinct for
                   instanceof to check against. The unbounded wildcard
                   form - instanceof List<?> - is legal precisely
                   because it asks only "is this some kind of List,"
                   which the erased runtime type CAN answer.

3. YOU CANNOT CREATE AN ARRAY WHOSE COMPONENT TYPE IS GENERIC

   Fresher view  : arrays remember and enforce their element type on
                   every store (ArrayStoreException). Generics do not
                   carry that information at runtime at all - the two
                   don't mix safely.

   Deeper view   : if new T[10] were legal, the JVM would have no
                   real component type to enforce array-store checks
                   against, silently defeating the one runtime safety
                   net arrays are built around. The workaround -
                   creating a raw array and casting, or using
                   Array.newInstance(Class<T>, size) - pushes the
                   unsafety into one explicitly-marked, reviewed spot
                   instead of leaving it implicit everywhere.

4. YOU CANNOT MIX GENERICS WITH STATIC CONTEXT, PRIMITIVES, OR THROWABLES

   Fresher view  : a class's own T belongs to each INSTANCE, not to
                   the class itself - so static members can't use it.
                   Primitives aren't objects, so they can't fill a
                   type argument slot. Exceptions are caught by their
                   runtime class, and erasure removes exactly the
                   information catch would need for a generic one.

   Deeper view   : a static member exists once per class, shared by
                   every parameterization - Cache<String,V> and
                   Cache<Integer,V> share ONE set of static members,
                   so there is no single T a static field could hold.
                   Primitives need autoboxing to become type arguments
                   (List<Integer>, not List<int>) because generics
                   were designed entirely around reference types.
                   Generic exception classes are banned because catch
                   blocks match against the exact runtime class of a
                   thrown object - if MyException<T> were legal, a
                   catch (MyException<String> e) block would need
                   erasure-defeating runtime information to know
                   which T a caught exception carried.

Cannot Instantiate a Type Parameter

Writing new T() inside a generic class is a compile error, because T erases to its bound before the class is compiled — there is no runtime class named T to construct. The two standard workarounds each supply, explicitly, the piece of information erasure removed.

Java

Try it out

// File: CannotInstantiateDemo.java

import java.util.*;
import java.util.function.Supplier;

public class CannotInstantiateDemo {

    static class BrokenFactory<T> {
        // T create() { return new T(); }   // COMPILE ERROR - cannot instantiate type variable T
    }

    // WORKAROUND 1 - accept a Supplier<T> factory from the caller
    static class SupplierFactory<T> {
        private final Supplier<T> creator;
        SupplierFactory(Supplier<T> creator) { this.creator = creator; }
        T create() { return creator.get(); }   // delegates - no "new T()" needed
    }

    // WORKAROUND 2 - accept a Class<T> token and use reflection
    static class ReflectiveFactory<T> {
        private final Class<T> type;
        ReflectiveFactory(Class<T> type) { this.type = type; }
        T create() throws ReflectiveOperationException {
            return type.getDeclaredConstructor().newInstance();
        }
    }

    static class Widget {
        private final String name;
        public Widget() { this.name = "default-widget"; }
        @Override public String toString() { return "Widget(" + name + ")"; }
    }

    public static void main(String[] args) throws Exception {

        System.out.println("=== Workaround 1 - Supplier<T> factory ===");
        SupplierFactory<ArrayList<String>> listFactory = new SupplierFactory<>(ArrayList::new);
        ArrayList<String> list = listFactory.create();
        list.add("Ananya");
        System.out.println("list: " + list);

        System.out.println();

        System.out.println("=== Workaround 2 - Class<T> token + reflection ===");
        ReflectiveFactory<Widget> widgetFactory = new ReflectiveFactory<>(Widget.class);
        Widget widget = widgetFactory.create();
        System.out.println("widget: " + widget);
    }
}

Output:
=== Workaround 1 - Supplier<T> factory ===
list: [Ananya]

=== Workaround 2 - Class<T> token + reflection ===
widget: Widget(default-widget)

Cannot Create Arrays of a Parameterized Type

new T[10] and new List<String>[5] are both compile errors, for the same underlying reason: arrays enforce their component type at every store at runtime, and erasure leaves no real component type behind for a generic array to enforce. Two workarounds exist — a raw array with an explicit cast, or avoiding arrays entirely in favor of nested collections.

Java

Try it out

// File: CannotCreateArrayDemo.java

import java.util.*;

public class CannotCreateArrayDemo {

    static class Box<T> {
        T value;
        Box(T value) { this.value = value; }
        @Override public String toString() { return "Box(" + value + ")"; }
    }

    @SuppressWarnings("unchecked")
    public static void main(String[] args) {

        System.out.println("=== new T[] and new List<String>[] are both compile errors ===");
        // T[] elements = new T[5];                     // COMPILE ERROR (inside a generic class)
        // List<String>[] lists = new List<String>[5];   // COMPILE ERROR - generic array creation
        System.out.println("Both forms rejected at compile time - see comments in source");

        System.out.println();

        System.out.println("=== Workaround 1 - raw array with an explicit unchecked cast ===");
        List<String>[] rawArray = (List<String>[]) new List[3];   // compiles - unchecked warning
        rawArray[0] = List.of("Mumbai", "Pune");
        rawArray[1] = List.of("Delhi");
        System.out.println("rawArray[0]: " + rawArray[0]);
        System.out.println("rawArray[1]: " + rawArray[1]);

        System.out.println();

        System.out.println("=== Workaround 2 (preferred) - a List of Lists, no array involved ===");
        List<List<String>> listOfLists = new ArrayList<>();
        listOfLists.add(List.of("Mumbai", "Pune"));
        listOfLists.add(List.of("Delhi"));
        System.out.println("listOfLists: " + listOfLists);

        System.out.println();

        System.out.println("=== Box<T>[] has the same restriction as List<T>[] ===");
        // Box<String>[] boxes = new Box<String>[3];   // COMPILE ERROR
        Box<String>[] boxesRaw = (Box<String>[]) new Box[3];   // compiles - unchecked warning
        boxesRaw[0] = new Box<>("Ananya");
        System.out.println("boxesRaw[0]: " + boxesRaw[0]);
    }
}

Output:
=== new T[] and new List<String>[] are both compile errors ===
Both forms rejected at compile time - see comments in source

=== Workaround 1 - raw array with an explicit unchecked cast ===
rawArray[0]: [Mumbai, Pune]
rawArray[1]: [Delhi]

=== Workaround 2 (preferred) - a List of Lists, no array involved ===
listOfLists: [[Mumbai, Pune], [Delhi]]

=== Box<T>[] has the same restriction as List<T>[] ===
boxesRaw[0]: Box(Ananya)

Cannot Use Primitive Types as Type Arguments

List<int> is a compile error — every type argument must be a reference type. Java works around this with autoboxing: List<Integer> accepts int values transparently, converting them to Integer on the way in and back on the way out, at the cost of object identity subtleties and a small amount of boxing overhead that primitive-specialized APIs like IntStream avoid entirely.

Java

Try it out

// File: NoPrimitivesDemo.java

import java.util.*;
import java.util.stream.IntStream;

public class NoPrimitivesDemo {

    public static void main(String[] args) {

        System.out.println("=== Primitive type arguments are a compile error ===");
        // List<int> numbers = new ArrayList<>();   // COMPILE ERROR - primitives cannot be type arguments
        List<Integer> numbers = new ArrayList<>();   // wrapper type required instead
        numbers.add(10);   // autoboxed: int 10 -> Integer.valueOf(10)
        numbers.add(20);
        int first = numbers.get(0);   // auto-unboxed: Integer -> int
        System.out.println("first (unboxed): " + first);
        System.out.println("numbers: " + numbers);

        System.out.println();

        System.out.println("=== Autoboxing has a real cost - identity vs equality ===");
        Integer a = 100;
        Integer b = 100;
        Integer c = 200;
        Integer d = 200;
        System.out.println("100 == 100 (cached)  : " + (a == b));   // Integer cache -128..127
        System.out.println("200 == 200 (uncached) : " + (c == d));  // outside cache range
        System.out.println("200.equals(200)       : " + c.equals(d));

        System.out.println();

        System.out.println("=== Primitive specializations avoid boxing entirely ===");
        IntStream.rangeClosed(1, 5).forEach(n -> System.out.print(n + " "));   // int throughout - no Integer boxing
        System.out.println();
    }
}

Output:
=== Primitive type arguments are a compile error ===
first (unboxed): 10
numbers: [10, 20]

=== Autoboxing has a real cost - identity vs equality ===
100 == 100 (cached)  : true
200 == 200 (uncached) : false
200.equals(200)       : true

=== Primitive specializations avoid boxing entirely ===
1 2 3 4 5

Cannot Mix Generics With Static Context or Throwable

A class's type parameter belongs to each instance, not to the class itself, so static members cannot reference it — they may declare their own, unrelated type parameter instead. Separately, no class may extend Throwable (directly or indirectly) while declaring its own type parameter, because catch blocks match against a thrown object's exact runtime class, and erasure removes precisely the information a generic catch would need.

Java

Try it out

// File: ClassLevelRestrictionsDemo.java

import java.util.*;

public class ClassLevelRestrictionsDemo {

    static class Counter<T> {
        // static T lastValue;   // COMPILE ERROR - non-static T cannot be referenced from a static context

        // CORRECT - static members declare their OWN type parameter instead
        static <U> U firstNonNull(U a, U b) {
            return a != null ? a : b;
        }

        private T value;
        void set(T value) { this.value = value; }
        T get() { return value; }
    }

    // static class GenericException<T> extends Exception { }   // COMPILE ERROR - a Throwable cannot be generic

    // CORRECT - carry the payload as a field on an ordinary, non-generic exception
    static class PayloadException extends Exception {
        private final Object payload;
        <T> PayloadException(String message, T payload) {
            super(message);
            this.payload = payload;
        }
        @SuppressWarnings("unchecked")
        <T> T getPayload() { return (T) payload; }
    }

    public static void main(String[] args) {

        System.out.println("=== Static members use their OWN type parameter, not the class's T ===");
        System.out.println("firstNonNull: " + Counter.<String>firstNonNull(null, "fallback"));

        System.out.println();

        System.out.println("=== Instance members freely use the class's T ===");
        Counter<Integer> counter = new Counter<>();
        counter.set(42);
        System.out.println("counter.get(): " + counter.get());

        System.out.println();

        System.out.println("=== A generic exception class is a compile error - carry payload as a field instead ===");
        try {
            throw new PayloadException("Order validation failed", "ORD-1042");
        } catch (PayloadException e) {
            String orderId = e.getPayload();
            System.out.println("Caught: " + e.getMessage() + " (payload=" + orderId + ")");
        }
    }
}

Output:
=== Static members use their OWN type parameter, not the class's T ===
firstNonNull: fallback

=== Instance members freely use the class's T ===
counter.get(): 42

=== A generic exception class is a compile error - carry payload as a field instead ===
Caught: Order validation failed (payload=ORD-1042)

Real-World Example - Urban Company Provider Onboarding

A service-marketplace backend onboards different provider types — plumbers, electricians — through a generic EntityFactory<T>. Since new T() is not legal, the factory takes a Class<T> token and uses reflection instead; since a generic exception class is not legal, the failure payload rides along as a field on an ordinary exception via a generic constructor; and the factory's static entry point declares its own type parameter rather than trying to reuse the enclosing class's.

Java

Try it out

// File: EntityFactory.java

public class EntityFactory<T> {

    private final Class<T> type;

    public EntityFactory(Class<T> type) {
        this.type = type;
    }

    // Workaround for "cannot instantiate T" - a Class<T> token supplies at
    // runtime exactly the information erasure discarded at compile time.
    public T create() throws OnboardingException {
        try {
            return type.getDeclaredConstructor().newInstance();
        } catch (ReflectiveOperationException e) {
            // Cannot be a generic exception class (OnboardingException<T> is
            // illegal), so the failing type name rides along as a plain payload.
            throw new OnboardingException("Could not onboard provider type", type.getSimpleName());
        }
    }

    // Static members declare their OWN type parameter - they cannot reuse
    // the enclosing class's T, because a static member belongs to
    // EntityFactory itself, not to any single EntityFactory<SomeType>.
    public static <U> EntityFactory<U> forType(Class<U> type) {
        return new EntityFactory<>(type);
    }
}

Java

Try it out

// File: OnboardingException.java

public class OnboardingException extends Exception {

    // The exception class itself CANNOT declare <T> - extending Throwable
    // forbids it. A generic constructor works fine and carries the payload.
    private final Object payload;

    public <T> OnboardingException(String message, T payload) {
        super(message);
        this.payload = payload;
    }

    @SuppressWarnings("unchecked")
    public <T> T getPayload() {
        return (T) payload;
    }
}

Java

Try it out

// File: ProviderOnboardingDemo.java

public class ProviderOnboardingDemo {

    public static class Plumber {
        private final String name;
        public Plumber() { this.name = "unassigned"; }
        @Override public String toString() { return "Plumber(" + name + ")"; }
    }

    public static class Electrician {
        // Deliberately NO no-arg constructor - only this one exists
        private final String certification;
        public Electrician(String certification) { this.certification = certification; }
        @Override public String toString() { return "Electrician(" + certification + ")"; }
    }

    public static void main(String[] args) {

        System.out.println("=== Class<T> token workaround for new T() ===");
        try {
            EntityFactory<Plumber> plumberFactory = EntityFactory.forType(Plumber.class);
            Plumber plumber = plumberFactory.create();
            System.out.println("Onboarded: " + plumber);
        } catch (OnboardingException e) {
            System.out.println("Never printed for Plumber");
        }

        System.out.println();

        System.out.println("=== The same restriction surfaces at runtime, not compile time, for bad T ===");
        try {
            EntityFactory<Electrician> electricianFactory = EntityFactory.forType(Electrician.class);
            Electrician electrician = electricianFactory.create();   // no no-arg constructor exists
            System.out.println("Never printed: " + electrician);
        } catch (OnboardingException e) {
            String failedType = e.getPayload();
            System.out.println("Onboarding failed: " + e.getMessage() + " (type=" + failedType + ")");
        }

        System.out.println();

        System.out.println("=== Static generic utility - its own <U>, unrelated to any EntityFactory<T> ===");
        EntityFactory<String> stringFactory = EntityFactory.forType(String.class);
        System.out.println("stringFactory created via static <U> forType(): " + (stringFactory != null));
    }
}

Output:
=== Class<T> token workaround for new T() ===
Onboarded: Plumber(unassigned)

=== The same restriction surfaces at runtime, not compile time, for bad T ===
Onboarding failed: Could not onboard provider type (type=Electrician)

=== Static generic utility - its own <U>, unrelated to any EntityFactory<T> ===
stringFactory created via static <U> forType(): true

EntityFactory<Plumber> and EntityFactory<Electrician> succeed or fail based purely on whether Class<T>.getDeclaredConstructor() finds a no-arg constructor at runtime — the restriction against new T() has been converted from a compile-time impossibility into an ordinary, catchable runtime condition, which is exactly what the Class<T> token workaround is for. OnboardingException shows the same trade for exceptions: it cannot be generic itself, but its generic constructor and generic getter let it carry a strongly-typed payload anyway.

Generics Restrictions - Quick Reference

Restriction	Why It's Illegal	Standard Workaround
`new T()`	`T` erases to its bound before any bytecode exists to instantiate	`Supplier<T>` factory, or a `Class<T>` token with reflection
`instanceof List<String>`	Erasure means no runtime distinction from `List<Integer>` exists	`instanceof List<?>` or the raw `instanceof List`
`new T[10]` / `new List<String>[5]`	No real component type for the array to enforce on each store	`Class<T>` token + `Array.newInstance()`, or a raw array with an explicit cast
`List<int>`	Type arguments must be reference types	`List<Integer>` - autoboxing bridges the gap
`static T field`	A static member is shared by every parameterization; there is no single `T`	Give the static member its own type parameter, e.g. `static <U> U m(U x)`
`class Foo<T> extends Exception`	`catch` matches by exact runtime class; erasure removes the `T` a catch would need	Keep the exception non-generic; carry `T` via a generic constructor/getter field
`void m(List<String>)` + `void m(List<Integer>)`	Both erase to the identical signature `m(List)`	Different method names, or wrap one type in its own class

Best Practices

Accept a Class<T> token wherever a generic API genuinely needs to create instances or arrays of T. This is the standard, idiomatic answer to the "cannot instantiate/cannot create an array of T" restrictions, used throughout the JDK (EnumSet.noneOf, Array.newInstance) and every major dependency-injection framework.

Give static members their own type parameter rather than trying to reach for the enclosing class's T. A static method like static <U> U firstNonNull(U a, U b) is a completely ordinary generic method — the restriction is only ever about referencing the instance-level type parameter from a static context, never about static members using generics at all.

Design exceptions to carry a strongly-typed payload through a generic constructor or getter, never through a generic class declaration. The exception class itself must stay non-generic to remain catchable, but nothing stops a constructor like <T> MyException(String msg, T payload) from preserving full type safety at the call site where the exception is thrown and caught.

Reach for List<T> before reaching for an array whenever a type parameter is involved. Every one of the array-related restrictions in this article disappears if the array was never created in the first place - a List<List<String>> needs no cast, no @SuppressWarnings, and no Class<T> token to construct safely.

Common Mistakes

Mistake 1 - Trying to Instantiate a Type Parameter Inline

Java

Try it out

// WRONG - new T() is illegal wherever T is a type variable, not just inside a factory class
static <T> T createDefault() {
    // return new T();   // COMPILE ERROR - cannot instantiate the type variable T
    return null;
}

// CORRECT - require the caller to supply a Supplier<T>
import java.util.function.Supplier;

static <T> T createDefault(Supplier<T> factory) {
    return factory.get();   // legal - the actual constructor call happens outside this method
}

Mistake 2 - Declaring a Static Field of the Class's Own Type Parameter

Java

Try it out

// WRONG - a static field cannot use the enclosing class's own type variable T
class Registry<T> {
    // static T lastRegistered;   // COMPILE ERROR - non-static T referenced from a static context
}

// CORRECT - store the value per-instance, or type the static field as Object
// and expose it through a method with its own type parameter
class Registry<T> {
    private T lastRegistered;
    void register(T value) { this.lastRegistered = value; }
    T last() { return lastRegistered; }
}

Mistake 3 - Declaring a Generic Exception Class

Java

Try it out

// WRONG - a class extending Throwable (directly or indirectly) cannot declare its own type parameter
// class ValidationException<T> extends Exception {
//     T invalidValue;
// }

// CORRECT - keep the exception class non-generic; carry the value through
// a generic constructor and a generic accessor instead
class ValidationException extends Exception {
    private final Object invalidValue;
    <T> ValidationException(String message, T invalidValue) {
        super(message);
        this.invalidValue = invalidValue;
    }
    @SuppressWarnings("unchecked")
    <T> T getInvalidValue() { return (T) invalidValue; }
}

Mistake 4 - Assuming a Wrapper Type Behaves Exactly Like Its Primitive

Java

Try it out

import java.util.*;

// WRONG ASSUMPTION - treating List<Integer> elements as if == compared them
// the way int == int would, ignoring the Integer cache boundary
List<Integer> ids = new ArrayList<>(List.of(200, 300));
Integer first = ids.get(0);
Integer sameValue = 200;
// if (first == sameValue) { }   // unreliable - true or false depends on caching, not logic

// CORRECT - always use equals() for wrapper type comparison, never ==
if (first.equals(sameValue)) {
    System.out.println("Equal by value, regardless of caching");
}

Interview Questions

Q1. Why is new T() illegal inside a generic class, and what are the standard workarounds?

T is erased to its bound (usually Object) before the class is compiled, so new T() would have to compile to new Object() — clearly not what the code intends — and the compiler refuses to allow it rather than silently doing the wrong thing. The two standard workarounds both supply, explicitly, the information erasure removed: accepting a Supplier<T> factory that the caller provides (simple, no reflection), or accepting a Class<T> token and calling getDeclaredConstructor().newInstance() on it (more flexible, works when the caller only has a Class reference available).

Q2. Why can't a static field be declared with the class's own type parameter?

A static member exists exactly once per class, shared by every instance regardless of how that instance was parameterized — Counter<String> and Counter<Integer> share the very same static members, because there is only one Counter.class at runtime. A static field of type T would therefore have no single, consistent type to hold across all the different Ts different instances use. Static members can still use generics freely; they simply must declare their own, independent type parameter (static <U> ...) rather than referencing the enclosing class's instance-level T.

Q3. Why can't a class that extends Exception or Throwable declare a type parameter?

catch blocks select which handler runs by comparing the thrown object's actual runtime class against the type named in each catch clause — an operation that, like instanceof, only ever sees the erased runtime type. If class ValidationException<T> extends Exception were legal, catch (ValidationException<String> e) would need runtime information about T that erasure has already discarded, making it impossible for the JVM to correctly distinguish it from catch (ValidationException<Integer> e). The restriction exists to prevent writing a catch clause the JVM could never actually honor. The standard workaround keeps the exception class itself non-generic and carries the typed payload through a generic constructor or accessor method instead.

Q4. Why is new T[10] illegal, and what is the standard workaround?

Arrays are reified in Java — every array remembers its component type at runtime and enforces it on every element store, throwing ArrayStoreException on a mismatch. A type variable T has no such runtime-known component type after erasure, so an array of T would have nothing real to enforce, defeating the purpose of array-store checking entirely. The standard workaround is to accept a Class<T> token and create the array via java.lang.reflect.Array.newInstance(type, size), which produces a genuinely correctly-typed array at runtime, or to create a raw array and cast it explicitly (accepting an unchecked warning) when a Class<T> token is not available.

Q5. Why can't List be written, and what does Java use instead?

Generic type arguments must be reference types because the entire generics implementation - erasure to Object or a bound, storage as object references inside collections - assumes every type argument is something that can be represented as, and cast from, a reference. Primitives like int are not objects and have no null value, so they cannot fill that role directly. Java's answer is autoboxing: List<Integer> is used instead of List<int>, and the compiler automatically inserts Integer.valueOf() and .intValue() calls at the boundaries so the primitive int and the wrapper Integer can be used almost interchangeably, at the cost of some boxing overhead and the well-known == versus .equals() pitfall with cached versus uncached Integer values.

Q6. Why can't two methods be overloaded by generic type argument alone, like process(List) and process(List)?

Method overload resolution and the class file's method table both operate on erased signatures, and List<String> and List<Integer> both erase to the identical parameter type List. Declaring both methods produces a genuine "name clash" compile error, not merely ambiguity at call sites - the compiler cannot generate two distinct methods with the same erased signature in one class file. The fix is to give the methods different names, or to wrap one of the type arguments in its own dedicated type so the erased signatures differ.

FAQs

Do any of these restrictions apply to bounded type parameters differently than unbounded ones?

No - every restriction in this article applies identically regardless of whether T is unbounded or declared as T extends SomeBound. The bound changes what T erases to (its declared bound instead of Object), which affects which methods are callable on a T value, but it has no effect on whether new T(), instanceof T, or new T[] are legal - none of them ever are, bound or no bound.

Can a generic class have a static nested class that IS generic with its own type parameter?

Yes, and this is a completely different situation from a static field or method trying to reuse the outer class's T. class Outer<T> { static class Node<U> { U value; } } is entirely legal - Node is a static member of Outer, but it declares its own independent type parameter U rather than referencing Outer's T. This exact pattern is how HashMap's internal Node<K,V> class is structured.

Is there any way to get true reification of generics in Java, similar to C#?

Not through the language's generics system itself. The closest tool is passing a Class<T> (or, for more complex generic types, a TypeToken-style captured supertype, a pattern popularized by libraries like Gson and Guice) explicitly alongside the generic type, which recreates at runtime the type information erasure discarded at compile time. This is a library-level workaround, not language-level reification - the language itself never stores per-instance type argument information.

Why is catch (T e) illegal even though throw new SomeException() works fine inside a generic method?

catch needs to check a thrown object's exact runtime class against the type named in the clause, and T has no runtime class of its own to check against - it erases away entirely. Throwing a specific, already-instantiated exception object from inside a generic method is completely unrelated and always legal, because that thrown object's own class is perfectly well-defined; the restriction is only about naming a type variable as the type being caught or as a class extending Throwable.

Does @SuppressWarnings make any of these restrictions go away?

No. @SuppressWarnings can only silence a warning about an operation the compiler already allows but cannot fully verify - such as an unchecked cast on a raw array. It has no effect on true compile errors like new T(), instanceof List<String>, or a generic exception class declaration; those remain illegal regardless of any annotation, because they are rejected by the language grammar and type-checking rules, not merely flagged with a warning.

Summary

Every restriction in this article is the same restriction, seen from a different angle: by the time a generic class's bytecode runs, the specific type argument it was written against no longer exists anywhere the JVM can see. new T(), instanceof List<String>, new T[], and catch (T e) are all attempts to ask the runtime a question only the compiler ever knew the answer to.

None of them are dead ends. Supplier<T> and Class<T> tokens answer the instantiation and array-creation questions by supplying the missing information explicitly, at the one call site that actually needs it. Giving static members and exception payloads their own independent type parameters sidesteps the restriction entirely rather than fighting it. Once the pattern is visible - erasure removes it, so hand it back in explicitly - every restriction in this list stops looking like an arbitrary rule and starts looking like the same rule, applied consistently.

What to Read Next

Continue Learning Generics

Next Step

Lambda Expressions

Learn how to write a small function in a single line.

→

Generic Interfaces

Learn how to write an interface that works with any data type.

→

Generic Classes

Learn how to write a class that works with any data type.

→

Collections Hierarchy

See how every collection type fits together.

→

←

PreviousType Erasure

NextLambda Expressions

→