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

Верхняя граница определяет, какие члены доступны параметру типа во время компиляции и во что он стирается в байткоде. Для параметра T стираемым типом становится его левая граница: Object для неограниченного параметра, класс или интерфейс для ограниченного. Поэтому граница влияет не только на проверку типов, но и на реальные сигнатуры методов после компиляции.

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

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

Для этого Java использует преимущественно стирание типов: параметры типов существуют для компилятора, но не представляются отдельными типами в обычных JVM-сигнатурах. Верхняя граница позволила сохранить сведения о минимально необходимом типе, не отказываясь от такой модели совместимости.

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

Если параметр типа не имеет границы, компилятор может гарантировать для него только операции, доступные у Object. Например, вызов метода, объявленного только в Number, для произвольного T недопустим.

Неверное понимание границы приводит и к ошибкам на уровне бинарной совместимости. Два метода с одинаковым исходным обобщённым объявлением, но разными границами могут получить разные стёртые JVM-сигнатуры. Уже скомпилированный клиент в таком случае способен перестать находить метод после обновления библиотеки.

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

Рассмотрим минимальный пример:

interface Named {
    String name();
}

class Reader {
    static <T extends Named> String read(T value) {
        return value.name();
    }
}

В исходном коде компилятор знает, что любой T реализует Named, поэтому разрешает вызов name(). После стирания параметр T заменяется на его левую границу Named; если бы границы не было, он заменился бы на Object.

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

Компилятор также вставляет необходимые приведения и проверки типов там, где после стирания это требуется для сохранения семантики исходного кода. Поэтому bound влияет на то, какой тип будет виден в байткоде и какие приведения потребуются.

Если задано несколько границ, стиранием становится первая граница. Именно поэтому класс, если он есть, располагают первым: JVM-типом для стирания должен быть один класс, а остальные ограничения используются компилятором как дополнительные гарантии.

Главный компромисс таков: более узкая граница предоставляет больше операций над T, но сильнее фиксирует контракт и может изменить стёртую сигнатуру. Более широкая граница повышает универсальность, однако ограничивает доступные операции и может потребовать дополнительных преобразований.

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

Команда публикует библиотечный метод преобразования числового значения:

class Numbers {
    static <T extends Number> T normalize(T value) {
        return value;
    }
}

Для исходного клиента параметр и результат метода стираются до Number. Если разработчик библиотеки заменит границу на Object, исходная Java-типизация может выглядеть похожей, но стёртая сигнатура изменится. Уже скомпилированный клиент, ожидающий метод с параметром и результатом Number, может получить ошибку связывания вроде NoSuchMethodError.

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

Практическое решение — считать изменение верхней границы изменением не только исходного generic-контракта, но потенциально и бинарного API. Для публичных библиотек границу следует выбирать осознанно и проверять совместимость уже скомпилированных клиентов.

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

Сохраняется ли верхняя граница в .class-файле после стирания?

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

Определяет ли граница поведение JVM при каждом вызове метода?

Не в полном виде. Проверка корректности обобщённого кода в основном выполняется компилятором, а после стирания JVM работает со стёртыми типами. Компилятор добавляет checkcast, когда это необходимо для восстановления ожидаемого конкретного типа; при ошибочном небезопасном использовании такая проверка может завершиться ClassCastException.

Может ли изменение границы быть совместимым с исходным кодом, но несовместимым с бинарным кодом?

Да. Клиент, перекомпилированный вместе с новой библиотекой, может успешно пройти проверку, потому что видит новую generic-сигнатуру. Но старый клиент обращается к конкретному стёртому JVM-дескриптору; если граница изменила этот дескриптор, загрузка или вызов метода может завершиться ошибкой связывания.

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