Краткий ответ

В Java нельзя напрямую создать массив параметризованного типа: стирание типов не позволяет JVM узнать компонентный тип вроде List<String> во время выполнения. Обход через приведение массива приводит к риску heap pollution: в массив можно поместить объект с другой параметризацией, а ошибка проявится позднее при извлечении элемента.

Исторический контекст

Generics появились в Java 5, когда в экосистеме уже существовали непараметризованные коллекции и большое количество бинарно скомпилированного кода. Для совместимости Java выбрала в основном стирание типов: параметры типов используются компилятором, но не сохраняются как отдельная информация о типе объекта во время выполнения.

Массивы существовали раньше и устроены иначе: они ковариантны и хранят компонентный тип во время выполнения. Например, массив строк знает, что его элементы должны быть строками, поэтому JVM может выполнить проверку при записи.

Постановка проблемы

Для массива параметризованных объектов требуются одновременно две гарантии: компилятор должен учитывать параметр типа, а JVM — проверять его при записи. После стирания List<String> и List<Integer> имеют один и тот же runtime-компонентный тип List, поэтому JVM не может проверить различие между ними.

Если разрешить обычное создание такого массива, запись списка другой параметризации могла бы пройти проверку массива. Ошибка обнаружилась бы только при чтении элемента и обычно проявилась бы как ClassCastException, далеко от места нарушения.

Подробное решение

Непосредственное создание массива параметризованного типа запрещено компилятором. Разрешается создать массив с непроверяемым или неограниченным компонентным типом, например List<?>[], но превращение его в List<String>[] требует непроверяемого приведения.

import java.util.List;

class Demo {
    public static void main(String[] args) {
        List<?>[] source = new List<?>[1];
        @SuppressWarnings("unchecked")
        List<String>[] strings = (List<String>[]) source;

        Object[] objects = strings;
        objects[0] = List.of(42); // проверяется только тип List

        String value = strings[0].get(0); // ClassCastException
    }
}

Массив во время выполнения проверяет лишь, что записываемый объект является List. Информация о String стерта, поэтому запись List<Integer> проходит, а неявное приведение результата get к String завершается исключением.

Безопасный общий подход — не создавать такой массив, а использовать List<List<String>>, коллекцию с подходящей параметризацией или передавать фабрику массива извне. Если массив действительно нужен, обычно применяют массив стираемого типа с тщательно локализованным непроверяемым приведением и документируют инвариант.

Отдельная связанная проблема возникает у generic varargs: массив параметризованных значений создаётся неявно. Поэтому компилятор может выдать предупреждение о непроверяемой операции; аннотация @SafeVarargs допустима только когда реализация действительно не создаёт опасной утечки или не изменяет содержимое varargs-массива небезопасным образом.

Ситуация из практики

Команда проектирует API, которое принимает несколько списков строк и хочет хранить их во внутреннем массиве. Вариант с List<String>[] выглядит естественно, но требует непроверяемого приведения и создаёт риск повреждения типовой безопасности через ссылку типа Object[].

Можно выбрать List<List<String>>: это безопасный и простой вариант, но он может потребовать адаптации кода, если вызывающая сторона уже работает с массивами. Можно использовать Object[]: это устраняет предупреждение о generic-массиве, но переносит проверки типов на ручную логику и ухудшает контракт API.

Предпочтительное решение — хранить данные в List<List<String>>, если нет строгого требования к массиву. Если совместимость с массивным API обязательна, создание реального массива выполняют через переданную фабрику или используют конкретный reifiable-компонентный тип, а непроверяемое приведение изолируют в одном проверенном месте.

Результат — отсутствие скрытого риска ClassCastException в обычном пути обработки и более ясный контракт для пользователей API. Цена решения — возможные дополнительные операции коллекции или необходимость изменить внутреннее представление данных.

Что кандидаты часто упускают

Почему массивы объектов нельзя считать полностью безопасной заменой generic-массивам?

Object[] действительно можно создать без стирания параметра типа, но он принимает значения любого ссылочного типа. Если логика ожидает только списки строк, компилятор больше не защищает этот инвариант. Такой вариант безопасен лишь при явных проверках или при строгом контроле всех записей.

Почему List<?>[] создать можно, а List<String>[] нельзя?

List<?> — reifiable type: во время выполнения не требуется различать неизвестный параметр типа. JVM достаточно знать, что компонентами массива являются объекты List. List<String> — нереифицируемый тип, поскольку сведения о String стираются, поэтому проверка массива не смогла бы подтвердить корректность записи.

Почему параметр типа T[] нельзя обычно создать внутри обобщённого метода?

На этапе выполнения T также стёрт, и JVM не знает, какой конкретный компонентный тип нужно передать инструкции создания массива. Поэтому безопасные варианты — принять готовый массив от вызывающего кода, принять фабрику массива или использовать коллекцию. Приведение массива Object[] к T[] может скомпилироваться с предупреждением, но не создаёт реальной проверки параметра T и потому требует особого обоснования.