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

Использование raw-типа отключает проверку параметров обобщённого типа на границе такого API. Старый метод может записать в коллекцию значение несовместимого типа, после чего ошибка проявится позже при чтении — обычно как ClassCastException.

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

class Legacy {
    static void addRaw(List values) {
        values.add(42);
    }
}

class Demo {
    public static void main(String[] args) {
        List<String> names = new ArrayList<>();
        Legacy.addRaw(names);
        String name = names.get(0);
    }
}

Вызов метода компилируется с предупреждением, но присваивание результата переменной String приводит к исключению: фактически в список попал Integer.

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

Generics появились в Java 5, чтобы добавить проверку типов на этапе компиляции и уменьшить необходимость в явных приведениях типов. При этом Java сохранила совместимость с кодом и библиотеками, созданными до появления обобщений.

Для совместимости существуют raw-типы — использование обобщённого класса без указания его параметров. Они позволяют старому коду работать с новыми параметризованными типами, но ценой потери статической типобезопасности.

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

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

В результате нарушение типа может находиться далеко от места возникновения. Запись проходит без немедленной ошибки, а исключение появляется только тогда, когда программа извлекает значение и ожидает конкретный тип.

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

Raw-тип — это обобщённый тип без аргумента типа, например List вместо List<String>. Операции через raw-тип рассматриваются компилятором как операции без полноценной проверки параметров, поэтому потенциально опасные места обычно сопровождаются предупреждениями unchecked.

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

При чтении из типизированной переменной компилятор вставляет необходимое приведение к ожидаемому типу. В примере это приводит к попытке привести фактический Integer к String, что вызывает ClassCastException.

Безопасный вариант — изменить legacy API на параметризованный метод или адаптировать его на границе системы с контролируемой проверкой данных. Если исходный API изменить нельзя, предупреждение можно подавить локально, но только после проверки его контракта; @SuppressWarnings не исправляет потенциальное нарушение типов.

В отличие от raw-типа, wildcard вроде List<?> сохраняет информацию о том, что коллекция параметризована некоторым неизвестным типом. Из неё можно безопасно читать значения как Object, но нельзя добавлять произвольные объекты, поэтому wildcard обычно предпочтительнее raw-типа для неизвестного параметра.

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

Сервис интеграции использовал старую библиотеку, метод которой принимал необобщённый список и добавлял в него служебные объекты. Новый код передал туда List<String>, потому что сигнатура позволяла это сделать после предупреждения компилятора. Ошибка проявилась только в другом компоненте, который обрабатывал список как набор строк.

Рассматривались три варианта:

оставить raw-тип и подавить предупреждение — быстро, но риск сохраняется;
передавать копию типа List<Object> — безопаснее для исходного списка, но требует адаптации и не всегда совместимо с API;
создать адаптер, который принимает типизированные данные, передаёт библиотеке отдельную коллекцию и проверяет результат — требует больше кода, зато изолирует небезопасную границу.

Выбран адаптер с отдельной коллекцией и проверкой результата. Небезопасное взаимодействие осталось в одном небольшом месте, а остальная часть приложения продолжила работать с List<String> без unchecked-операций и скрытого загрязнения кучи.

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

Почему компилятор выдаёт предупреждение, а не всегда запрещает вызов raw-типа?

Причина — совместимость с дообобщёнными библиотеками и байткодом. Если бы использование старых API стало ошибкой компиляции, значительную часть существующего Java-кода пришлось бы полностью переписывать. Поэтому компилятор разрешает операцию, но сигнализирует о потенциальной потере типобезопасности.
Где именно обычно возникает ClassCastException после записи через raw-тип?

Обычно не в момент добавления, потому что метод add принимает Object, а фактический параметр String не проверяется JVM. Исключение возникает при извлечении, когда байткод выполняет приведение к типу, который ожидается статической переменной или вызывающим кодом. Однако конкретная точка сбоя может отличаться, если библиотека сама выполняет приведения или вызывает типоспецифичные методы.
Почему замена raw-типа на wildcard не всегда является механической заменой?

List<?> запрещает добавлять в коллекцию произвольные значения, поскольку её конкретный параметр неизвестен. Поэтому такой тип подходит для чтения, но не для API, которое должно добавлять элементы. Если API должен добавлять значения, нужно выразить это через конкретный параметр типа или подходящую границу, а не возвращаться к raw-типу.