Generics и wildcards в Java

Стирание и инвариантность

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

Второе следствие - инвариантность: List<Cat> НЕ считается подтипом List<Animal>. Если бы компилятор это разрешил, через ссылку типа List<Animal> в список котов можно было бы положить собаку, и типобезопасность рухнула бы молча.

// Контраст, который любят на собеседовании: массивы, наоборот, ковариантны. Cat[] присваивается в Animal[] без единого возражения - я проверил, компилируется и работает. А запись собаки в такой массив падает в рантайме с ArrayStoreException. Дженерики выбрали строгость на компиляции, массивы - свободу с миной внутри.

стирание типов

параметры типов исчезают после компиляции

инвариантность

List<Cat> не подтип List<Animal>, в отличие от массивов

Wildcards и PECS

Инвариантность мешает писать общие методы, и для этого есть подстановочные знаки. Написал метод с параметром List<? extends Animal> и попробовал добавить туда кота. Компилятор ответил: incompatible types: Cat cannot be converted to CAP#1, где CAP#1 - свежая типовая переменная.

Расшифровывается это так. Знак «extends» значит «какой-то конкретный подтип Animal, но какой именно - неизвестно». Под ссылкой может лежать список котов, а может собак. Класть туда нельзя ничего, кроме null, зато читать безопасно: что бы там ни было, это точно Animal.

Зеркальный случай - List<? super Cat>, то есть «какой-то надтип кота». Туда кот войдёт всегда, а вот читать оттуда можно лишь как Object. Мнемоника PECS ровно про это: коллекция отдаёт (producer) - пишем extends, коллекция принимает (consumer) - пишем super.

// Отдельно про знак вопроса без границ: из List<?> можно читать как Object и добавлять только null. Это НЕ то же самое, что список без параметра вообще - тот отключает проверки дженериков целиком и оставлен для совместимости со старым кодом.

void feed(List<? extends Animal> zoo) {
    Animal a = zoo.get(0); // читать можно
    zoo.add(new Cat());    // не компилируется: Cat cannot be converted to CAP#1
}

PECS

producer extends, consumer super

сырой тип

дженерик без параметра: проверки выключены целиком

Что ещё нельзя и почему

Из стирания выводится весь список запретов. Нельзя создать массив параметризованного типа - рантайм не знает, какой это тип. У статических членов нет доступа к параметру типа класса, потому что параметр живёт в экземпляре. И перегрузки, различающиеся только параметром типа, не компилируются - мы это уже видели.

Переменное число аргументов с дженериками создаёт массив стёртого типа, отсюда предупреждение о загрязнении кучи: переменная одного типа начинает ссылаться на объект другого. Аннотация @SafeVarargs - это осознанная подпись «я не выпускаю этот массив наружу», а не способ заглушить предупреждение.

// Достать параметр типа в рантайме можно только окольно - через сигнатуры полей и методов или через анонимный подкласс, который сохраняет параметр в метаданных супертипа. Именно поэтому в Jackson пишут TypeReference с фигурными скобками на конце: это анонимный класс, а не декоративный синтаксис.

загрязнение кучи

переменная типа ссылается на объект другого типа

анонимный подкласс

приём, сохраняющий параметр типа в метаданных

Как отвечать: «Почему в List<? extends Animal> нельзя добавить элемент?»

Потому что «extends» означает «какой-то конкретный подтип Animal, но компилятор не знает какой». Под этой ссылкой может лежать список котов, и если бы добавить собаку разрешили, список котов оказался бы испорчен без единого предупреждения. Поэтому запись запрещена целиком - даже добавить Animal нельзя, можно разве что null. Я специально смотрел, как это выглядит: компилятор говорит, что Cat не может быть преобразован в CAP#1, то есть в свежую типовую переменную, которой он обозначил этот неизвестный подтип. Читать при этом безопасно: что бы там ни лежало, это точно Animal. Это и есть первая половина мнемоники PECS: коллекция-источник объявляется через extends. Когда мне надо класть, я переворачиваю на super: в List<? super Cat> кот войдёт всегда, а чтение отдаст только Object. И для контраста помню, что массивы устроены наоборот - они ковариантны, Cat[] присваивается в Animal[], а расплата приходит в рантайме через ArrayStoreException.

Сильный ответ: не правило наизусть, а вывод из угрозы типобезопасности, с точной формулировкой компилятора и парным случаем super. Контраст с массивами показывает, что человек понимает, какой размен выбрали дженерики.

На чём валят

• −Считают, что List<String> можно передать туда, где ждут List<Object>. Дженерики инвариантны, это не массивы.
• −Пишут instanceof с параметром типа. Ответ компилятора: Object cannot be safely cast to List<String>.
• −Пробуют добавить элемент в List<? extends Animal>. Нельзя ничего, кроме null: это источник, а не приёмник.
• −Переходят на сырой тип «чтобы скомпилировалось». Проверки выключаются целиком, и ClassCastException переезжает в рантайм к коллеге.
• −Объявляют перегрузки, различающиеся только параметром типа. После стирания это один метод: name clash, have the same erasure.