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

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

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

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

Такой подход позволяет обобщённому коду работать на JVM без создания отдельного runtime-представления для каждой параметризации. Компромисс состоит в том, что некоторые проверки типов нельзя выполнить полностью во время выполнения.

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

Рассмотрим объект, фактическое содержимое которого не соответствует ожидаемому параметру типа. Если выполнить непроверяемое приведение к List<String>, JVM не сможет надёжно проверить наличие именно строк внутри списка: во время выполнения доступен только тип List.

Неверное решение создаёт ложное ощущение типобезопасности. Ошибка обнаруживается не в месте приведения, а позже — в операции, где значение используется как String. Это усложняет диагностику и может привести к сбою далеко от источника проблемы.

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

Компилятор стирает аргументы типа у большинства параметризованных типов. В результате проверка приведения к List<String> фактически сводится к проверке совместимости с List; параметр String не проверяется JVM.

import java.util.ArrayList;
import java.util.List;

class Demo {
    public static void main(String[] args) {
        List<Integer> numbers = new ArrayList<>();
        numbers.add(10);
        Object value = numbers;
        List<String> text = (List<String>) value;
        String s = text.get(0);
    }
}

В этом примере приведение к List<String> обычно сопровождается предупреждением unchecked, но само по себе проходит. При вызове get(0) компилятор добавляет проверку результата на String; фактическое значение является Integer, поэтому возникает ClassCastException.

Важно отличать два уровня контроля. Компилятор проверяет корректность операций исходя из объявленного типа List<String>, а JVM проверяет только те свойства, которые доступны после стирания. Поэтому непроверяемое приведение следует локализовать, документировать и по возможности заменить проверкой содержимого или API, принимающим Class<T> и выполняющим явную проверку элементов.

Преобразование не обязательно всегда приводит к немедленному исключению. Если список пуст, чтения элемента не будет; если значение никогда не извлекается как String, ошибка также может не проявиться. Это делает загрязнение кучи особенно опасным: некорректное состояние существует раньше, чем становится наблюдаемым.

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

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

Вариант с проверкой только самого списка недостаточен, потому что проверяется лишь List, а не каждый элемент. Проверка всех элементов надёжнее, но требует обхода коллекции, может иметь стоимость по времени и должна явно определить поведение для null и неподходящих значений.

Предпочтительное решение — изменить границу API так, чтобы она возвращала типизированную коллекцию или принимала Class<String> для проверки элементов. Если изменить старый контракт невозможно, непроверяемое приведение следует оставить в одном адаптере, сразу валидировать содержимое и не распространять предупреждение по остальному коду. Тогда потенциальный сбой происходит на границе интеграции, а не в произвольном месте приложения.

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

Всегда ли непроверяемое приведение к параметризованному типу немедленно вызывает ClassCastException?

Нет. После стирания JVM может проверить только сырой тип, поэтому само приведение часто завершается успешно. Исключение появляется при операции, требующей конкретного параметра типа, например при извлечении элемента и приведении его к String.

Почему компилятор вообще разрешает такое приведение, если оно небезопасно?

Потому что Java должна поддерживать взаимодействие с legacy-кодом и raw-типами, где параметризация недоступна. Компилятор разрешает операцию как потенциально совместимую, но выдаёт предупреждение unchecked, сигнализируя об утрате статической гарантии.

Можно ли восстановить параметр типа через reflection у обычного объекта списка?

Нет, у экземпляра ArrayList<String> runtime-тип обычно остаётся ArrayList, без информации о том, что список предназначен для String. Reflection может увидеть параметры в объявлениях классов, полей или методов, если они записаны в байткоде как сигнатуры, но это не доказывает тип элементов конкретного объекта во время выполнения.