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

В параметре типа Java допускается не более одной границы-класса, и она должна стоять первой; после неё указываются интерфейсные границы. Первая граница определяет стирание типа, поэтому при нескольких границах параметр типа во время выполнения представляется именно этой границей-классом.

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

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

Несколько границ позволяют описать не только базовый класс объекта, но и требуемые возможности его интерфейсов. Например, алгоритм может требовать наследование от определённого класса, поддержку сравнения и сериализации.

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

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

Неверный порядок приводит к ошибке компиляции. Если первой указать интерфейс, а затем класс, нарушается синтаксическое правило языка; если выбрать неподходящий класс первой границей, стирание изменит доступные гарантии и может потребовать дополнительные приведения.

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

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

Первая граница называется левой границей и определяет стирание параметра типа. Для параметра T с границами Base, Comparable<T> и Serializable стирание T будет равно Base; остальные границы сохраняются как ограничения компиляции и учитываются при генерации проверок и приведений.

class Entity {
}

class User extends Entity
        implements Comparable<User>, java.io.Serializable {
    public int compareTo(User other) { return 0; }
}

class Demo {
    static <T extends Entity & Comparable<T> & java.io.Serializable>
    int order(T left, T right) {
        return left.compareTo(right);
    }
}

В этом примере Entity обязан стоять первым. Компилятор знает, что у T есть методы Entity, Comparable<T> и Serializable, но после стирания базовым представлением T становится Entity. Для вызовов методов интерфейсных границ компилятор при необходимости добавляет проверяемые приведения.

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

Выбор первой границы — не только вопрос синтаксиса. Он влияет на стирание, совместимость с байткодом и набор операций, которые компилятор сможет выполнять без явного приведения после стирания.

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

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

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

Результат: вызов метода разрешён только для подходящих типов, IDE и компилятор видят необходимые операции, а после стирания сохраняется совместимость с моделью Java, где у параметра есть одна основная runtime-представление.

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

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

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

Причина не только в удобстве синтаксиса: Java поддерживает одиночное наследование классов, а параметр типа не может одновременно получить два разных класса как верхние границы.

Определяют ли интерфейсные границы стирание, если класс указан первым?

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

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

Что изменится, если первым поставить слишком общий класс, например Object?

Сигнатура может стать формально допустимой, но стирание T будет происходить до Object. Это ухудшит основное runtime-представление параметра и может привести к большему числу добавленных приведений для операций, заданных интерфейсными границами.

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