Introduction

Java developers run into generic arrays early because arrays are convenient and generics are the normal way to express type-safe APIs. The catch is that Java does not let you write new T[10] directly, because arrays keep runtime element-type information while generic type parameters are erased at runtime.

Why new T[] Is Not Allowed

Java arrays are reified, which means they know and enforce their component type at runtime. Generics use type erasure, which means the type parameter T is mostly gone after compilation. Those two models do not fit together safely.

If Java allowed direct generic array creation, code like this could become unsound:

1import java.util.List;
2
3public class Demo {
4    public static void main(String[] args) {
5        List<String>[] stringLists = null;
6        Object[] objects = stringLists;
7        objects[0] = List.of(1, 2, 3);
8    }
9}

That kind of assignment would let the wrong runtime type enter an array that claims to hold List<String>. To avoid these problems, Java forbids direct creation of arrays whose component type is a type parameter or a parameterized type.

Create the Array With Reflection

If you truly need an array whose component type is provided at runtime, use Array.newInstance and cast the result.

1import java.lang.reflect.Array;
2import java.util.Arrays;
3
4public class GenericArrayFactory {
5    @SuppressWarnings("unchecked")
6    public static <T> T[] newArray(Class<T> type, int length) {
7        return (T[]) Array.newInstance(type, length);
8    }
9
10    public static void main(String[] args) {
11        String[] names = newArray(String.class, 3);
12        names[0] = "Alice";
13        names[1] = "Bob";
14        names[2] = "Cara";
15        System.out.println(Arrays.toString(names));
16    }
17}

This is the standard workaround because the Class<T> token gives the runtime the information needed to create the right array type.

Store Generic Data in a Collection Instead

In many cases the better answer is not to use an array at all. If the goal is just "a sequence of T values," a List<T> is more natural and avoids the awkward cast.

1import java.util.ArrayList;
2import java.util.List;
3
4public class Demo {
5    public static void main(String[] args) {
6        List<String> names = new ArrayList<>();
7        names.add("Alice");
8        names.add("Bob");
9        System.out.println(names);
10    }
11}

Collections are usually easier to resize, easier to pass around in APIs, and more idiomatic for generic code. If you are designing a library today, a List<T> is often the safer abstraction unless array semantics are specifically required.

A Common Pattern Inside Generic Classes

You may still need an internal array inside a generic class, especially when implementing stacks, queues, or hash tables. In that case, many implementations use an Object[] internally and cast on read.

1public class SimpleStack<T> {
2    private final Object[] elements;
3    private int size;
4
5    public SimpleStack(int capacity) {
6        this.elements = new Object[capacity];
7    }
8
9    public void push(T value) {
10        elements[size++] = value;
11    }
12
13    @SuppressWarnings("unchecked")
14    public T pop() {
15        T value = (T) elements[--size];
16        elements[size] = null;
17        return value;
18    }
19
20    public static void main(String[] args) {
21        SimpleStack<String> stack = new SimpleStack<>(5);
22        stack.push("one");
23        stack.push("two");
24        System.out.println(stack.pop());
25    }
26}

This pattern is common because the array is fully encapsulated. The unchecked cast is limited to one internal point instead of being spread across user code.

Arrays of Parameterized Types Are Still Tricky

Even with reflection, be careful about arrays whose component type is itself parameterized. For example, List<String>[] is still awkward because List.class does not preserve String at runtime. That is why you will often see List<?>[] or, better, List<List<String>> used instead.

If the parameterized element type matters to the API, a nested collection is usually the clearer option.

Common Pitfalls

The first pitfall is assuming new T[size] should work because T looks like a normal type. It is not available as a concrete runtime component type.

Another issue is using reflection but hiding the unchecked cast everywhere. Keep the cast in one helper method or one well-tested class so the rest of the code stays type-safe.

Developers also often reach for arrays when a List<T> would do the job better. Arrays are appropriate when fixed size, interop, or memory layout truly matters. Otherwise, collections are the simpler design.

Summary

• Java forbids direct generic array creation because generics are erased and arrays are runtime-typed.
• Use Array.newInstance with a Class<T> token when you really need an array of T.
• Prefer List<T> when array-specific behavior is not required.
• Internal Object[] storage is a common implementation detail in generic data structures.
• Be especially cautious with arrays of parameterized types such as List<String>[].