Generic Restrictions

Because a type parameter like T belongs to each object separately, but a static field is shared by the whole class. The class can't agree on one T for all objects, so Java forbids it.

Java removes the generic part at compile time, so both methods become method(List). That leaves two methods with the same name and same parameter types, which is not allowed.

Java erases the generic type T at compile time, so at runtime the program doesn't know which class T is and can't call its constructor. The usual fix is to pass a Class<T> object and call clazz.getDeclaredConstructor().newInstance(), or pass a factory/supplier that creates the object for you.

Java erases generic type info at compile time, so at runtime there is no String type stored inside the list to check against. You can only write obj instanceof List<?> (the unbounded wildcard) or obj instanceof List (raw).

Two big bugs. First, an Integer can be null, and unboxing a null throws NullPointerException. Second, comparing boxed numbers with == compares object identity, not value, so it can give wrong results; use equals() or compare as primitives.

Arrays in Java remember their element type at runtime and check every store against it, but generic types are erased and lost at runtime. Allowing generic arrays would let bad values slip in undetected, so the compiler forbids new T[] and new List<String>[]. The common fix is to create an Object[] (or use Array.newInstance with a Class token) and cast.

Use a Supplier<T> (or factory) when you just need to make new objects — it's simple, checked by the compiler, works with any constructor, and uses no reflection. Use a Class<T> token when you also need the actual class for other reasons, like reflection, casting, or building a real typed array.

A type token is a Class object (like String.class) you pass into a method so the code knows the type at runtime. It's needed because Java generics forget their type at runtime, so passing the Class restores that information.

A type token is just a Class<T> object (like String.class) that you pass into generic code. Because the Class object still knows the concrete type at runtime, the code can use it to create instances, cast, or build arrays even though the type parameter T itself was erased.

Java forbids it. A type that can be thrown and caught must be a real, fixed type at runtime, but generics are erased and lose their type info, so the compiler blocks any generic subclass of Throwable.

You can't ask the list its element type — that was erased. Test it with instanceof List<?>, then look at an actual element (list.get(0) instanceof String). This fails for an empty list, where the element type is simply unknowable at runtime.

Each number in a List<Integer> becomes a separate object on the heap with extra memory, plus the cost of boxing and unboxing. An int[] stores the raw numbers compactly with no boxing. It matters most for large data or tight loops.

Give the static method its own type parameter, like static <U> U pick(U x). That U is decided each time you call the method, not per object, so it doesn't clash with the rule.

Give the methods different names, or make them differ in their raw parameter types, or add an extra parameter. You cannot keep the same name with only the type argument different.

Class.cast checks at runtime that the object really is of the token's type and returns it typed, throwing ClassCastException right away if not. A plain (T) cast is erased, so it doesn't actually check T and the failure can surface later somewhere else.

You can't catch a type variable. A catch clause needs a concrete exception type the JVM can test at runtime, but T is erased and not known at runtime, so the compiler rejects catch (T e).

A reifiable type is one whose full type information is still available at runtime. Plain types, raw types, and unbounded wildcards like List<?> are reifiable; parameterized types like List<String> are not, because erasure throws the type argument away.

At runtime T is erased to Object (or its bound), so there is no real T to test against — x instanceof T and new T() are both illegal. The fix is to pass a Class<T> object and use clazz.isInstance(x) and clazz.getDeclaredConstructor().newInstance().

Arrays are a built-in language feature that knew about primitives from day one and the JVM has separate bytecode for primitive arrays. Generics were added later and use type erasure, where elements are treated as Object, which can't hold a primitive. So arrays got primitives, generics didn't.

At runtime Java erases the type argument, so there's only one class object (Box.class) shared by Box<String> and Box<Integer>. With a single shared class there's nowhere to store a separate static value per type, so a static member tied to T can't exist.

Java forbids two methods in a class whose names and erased parameter types match. After erasure the generic parts are gone, so such methods would be indistinguishable, which is the rule the compiler enforces.

A super type token captures a full generic type like List<String> by creating an anonymous subclass that fixes the type argument. Java writes that argument into the class's Signature metadata, and the token reads it back at runtime with getGenericSuperclass — something a plain Class can't do.

Java chose erasure so that generic code stays fully compatible with older non-generic code and runs on the existing JVM without changing the bytecode format. The price is that type arguments vanish at runtime, which is why you can't do new T(), new T[], obj instanceof T, or overload methods that differ only by their type argument.

Catch a concrete supertype (like Exception) instead of a type parameter, or list the specific exception types with multi-catch (catch (IOException | SQLException e)). You can also declare throws T and let the caller handle it.

A static field is shared by all instances of the class, and Java erases the type argument, so Counter<String> and Counter<Integer> use the very same static counter — not separate ones. To count per type, key a map by the Class object, e.g. a Map<Class<?>, Integer>.

The restrictions exist because Java erases generic types at runtime, so the JVM can't tell parameterized exceptions apart. A language that keeps (reifies) generic types at runtime could allow generic exceptions and catching type variables — but Java chose erasure to stay backward compatible.

C# reifies generics: the runtime keeps the type argument, so obj is List<string> works. Java erases generics, so the type argument is gone at runtime and the check is impossible. Java chose erasure to stay backward-compatible with pre-generics code and bytecode.

Avoid generic collections of wrappers. Use primitive arrays (int[], long[]) or primitive streams (IntStream) for the hot path, and reach for primitive-collection libraries like fastutil or Eclipse Collections when you need growable maps/lists of primitives without boxing.

Java chose to add generics by erasing type arguments so old (pre-generics) code and bytecode kept working. Erasure means one runtime class per generic class, so there's no per-type static storage — making static members of T impossible. Reified languages like C# kept per-type runtime types, so they can have such statics.