Why can't you write `new T()` inside a generic class or method in Java, and what is the standard workaround?

## The problem A **generic class** or **generic method** is parameterized by a *type parameter* — a placeholder like `T` that stands for some real type the caller chooses, e.g. `class Box<T>` or `<T> T make()`. You might naturally want to create a fresh `T` inside such code: ```java class Box<T> { T value = new T(); // DOES NOT COMPILE } ``` The compiler rejects this. To understand why, you need **type erasure**. ## What type erasure is Java added generics in Java 5 but had to stay backward-compatible with pre-generics code and with the existing JVM. The chosen implementation is *erasure*: generics are a **compile-time-only** feature. The compiler checks your types, then **erases** the type parameters from the bytecode. Every `T` is replaced by its *bound* — `Object` if `T` is unbounded, or the leftmost bound if you wrote `<T extends Number>` (then `T` becomes `Number`). The compiler inserts hidden casts where needed so the code still behaves correctly. The consequence: **at runtime, a `Box<String>` and a `Box<Integer>` are the exact same class `Box`** — there is no stored memory of what `T` was. The type argument is simply *not present* at runtime. This is called the type parameter being *non-reifiable* (a *reifiable* type is one whose full type information survives to runtime; generic type arguments are not reifiable). ## Why `new T()` fails To execute `new SomeClass()`, the JVM must (a) know the exact class to allocate and (b) know which constructor to call. With `new T()`, after erasure there is no class named `T` and no way to recover the concrete type the caller picked. The compiler also can't even prove that `T` *has* a no-argument constructor. So `new T()` is forbidden outright — it is a compile error, not a runtime surprise. ## Workaround 1: pass a `Class<T>` type token The caller hands you a *type token* — a `Class<T>` object that *does* carry the concrete class at runtime — and you instantiate reflectively: ```java static <T> T make(Class<T> type) throws ReflectiveOperationException { return type.getDeclaredConstructor().newInstance(); } // call: String s = make(String.class); ``` Downsides: it only works if `T` has an accessible matching constructor; it throws *reflective* exceptions at runtime instead of giving compile-time safety; and constructors that need arguments are awkward. (Note: `Class.newInstance()` is deprecated since Java 9 — use `getDeclaredConstructor().newInstance()`.) ## Workaround 2: pass a factory / `Supplier<T>` (preferred) Let the caller supply the construction logic: ```java static <T> T make(Supplier<T> factory) { return factory.get(); } // call: StringBuilder sb = make(StringBuilder::new); Point p = make(() -> new Point(1, 2)); // constructor with args, no problem ``` This is **type-safe at compile time**, needs no reflection, naturally supports constructor arguments, and fails fast if the type can't be built. For these reasons it is the modern idiom; the `Class<T>` token is mostly used when you also need the class for other reflective reasons (e.g. frameworks). ## Key takeaway You cannot directly instantiate a type parameter because erasure removes the type at runtime. Move the *act of creation* to something that does know the type: a `Class<T>` token (reflection) or, better, a `Supplier<T>`/factory provided by the caller.