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

Wildcard в Java допускает только одну одностороннюю границу: верхнюю через extends или нижнюю через super. Запись, одновременно ограничивающая неизвестный тип сверху и снизу, не поддерживается языком, поскольку модель wildcard основана на одном направлении неизвестной параметризации.

Это не означает, что интервал типов математически невозможен. Ограничение относится именно к синтаксису и системе типов Java: для сложных зависимостей обычно применяют именованный параметр типа, разделяют операции чтения и записи или уточняют контракт API другим способом.

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

Обобщения Java создавались как средство повысить типобезопасность коллекций и переиспользовать обобщённый код без дублирования для разных типов. При этом язык должен был сохранить совместимость с существующим кодом и выразить отношения подтипов через wildcard на месте использования.

Для этой задачи выбрали простую модель: ? extends T описывает неизвестный тип, ограниченный сверху, а ? super T — неизвестный тип, ограниченный снизу. Такая модель хорошо поддерживает типичные сценарии производителя и потребителя, но не является полноценным описанием произвольных интервалов типов.

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

Предположим, API хочет принять коллекцию неизвестного типа, который одновременно является подтипом Number и супертипом Integer. Интуитивно это выглядело бы как требование: безопасно читать значения как Number и добавлять значения Integer.

Java не позволяет выразить такой wildcard. Попытка совместить extends и super в одной параметризации является ошибочной, а выбор только одной границы теряет часть требуемой информации:

? extends Number безопасен для чтения как Number, но не позволяет добавлять произвольный Integer;
? super Integer позволяет добавлять Integer, но при чтении гарантирует только Object.

Неверный выбор приводит либо к ошибке компиляции при использовании коллекции, либо к чрезмерно слабому контракту и небезопасным приведéниям типов.

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

У wildcard есть две разные семантики.

? extends U означает: существует некоторый неизвестный тип T, для которого T является подтипом U. Поэтому из такой структуры можно извлечь значение как U, но нельзя безопасно добавить туда значение типа U: фактическим типом может оказаться, например, Integer, Double или другой подтип.

? super L означает: существует некоторый неизвестный тип T, для которого T является супертипом L. В такую структуру безопасно добавить L, потому что любой допустимый супертип обязан принимать значения L. Но при чтении известна только нижняя граница размещения, поэтому гарантированно получить можно лишь Object.

В Java эти формы являются альтернативами, а не двумя частями одного ограничения. У wildcard нет конструкции для задания диапазона вида «T находится между L и U». Даже если такой диапазон логически непротиворечив, компилятор не выводит его автоматически из комбинации независимых wildcard.

Минимальная иллюстрация двух поддерживаемых направлений:

import java.util.List;

void readNumbers(List<? extends Number> values) {
    Number value = values.get(0);
}

void addIntegers(List<? super Integer> values) {
    values.add(1);
    Object value = values.get(0);
}

Именованный параметр типа позволяет задать верхнюю границу, но не добавляет к ней нижнюю границу: Java не поддерживает lower bound для параметра типа. Поэтому при необходимости одновременно читать и записывать значения обычно проектируют API с двумя ролями коллекций — источником ? extends Number и приёмником ? super Integer — либо используют конкретный тип параметра, если это приемлемо для контракта.

Важно отличать ограничение wildcard от проверки фактического типа во время выполнения. Из-за стирания типов JVM не хранит полноценный параметр wildcard как runtime-условие; это ограничение проверяется в основном компилятором при статическом анализе программы.

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

В библиотеке обработки чисел потребовался метод, который читает любые числовые значения и передаёт целые значения в выходную коллекцию. Разработчик попытался описать один параметр как коллекцию типа, который одновременно расширяет Number и принимает Integer.

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

? extends Number — хорошо подходит для входного источника, но не позволяет добавлять в него значения;
? super Integer — хорошо подходит для выходного приёмника, но чтение возвращает только Object;
конкретный List<Number> — проще использовать, но он отвергает List<Integer> из-за инвариантности параметризации;
разделение входа и выхода на два параметра — точнее всего отражает разные гарантии и сохраняет типобезопасность.

Выбрали последний вариант: вход описали как источник ? extends Number, а выход — как приёмник ? super Integer. Это не пытается выразить несуществующий в Java двусторонний wildcard и явно фиксирует разные права доступа к двум коллекциям.

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

Можно ли заменить двустороннее ограничение параметром типа с верхней границей?

Частично. Параметр типа с верхней границей, например T extends Number, позволяет сохранить один конкретный тип и использовать операции, доступные для Number. Однако Java не предоставляет нижнюю границу для T, поэтому условие «T является супертипом Integer» таким способом задать нельзя.

Параметр типа полезен, когда несколько аргументов метода должны иметь один и тот же конкретный тип. Но он не является универсальной заменой диапазона wildcard.
Почему нельзя просто выбрать ? extends Number и разрешить добавление Integer как допустимого подтипа?

Потому что фактический тип коллекции может быть уже более узким подтипом Number. В коллекцию List<Integer> нельзя добавить Double, а компилятор не имеет права считать любую коллекцию ? extends Number коллекцией, принимающей каждый подтип Number.

Для чтения направление безопасно: любое значение из такой коллекции действительно является Number. Для записи требуется знать точный тип элемента, а wildcard этот тип скрывает.
Почему ? super Integer не даёт гарантии чтения как Number, хотя Integer является Number?

Коллекция с ? super Integer может иметь фактический тип Integer, Number или Object. Значение, извлечённое из неё, статически имеет тип Object, поскольку только это безопасно для всех перечисленных вариантов.

То, что в коллекцию можно добавить Integer, не означает, что каждое значение, уже находящееся в ней, является Integer или даже Number: коллекция типа Object могла содержать другие объекты. Поэтому операции чтения и записи имеют асимметричные гарантии.