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

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

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

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

Обобщённые типы появились в Java 5, но JVM сохраняет модель байткода без полноценной информации о параметрах типов. Для совместимости с существующим байткодом Java использует стирание типов: например, T обычно превращается в Object.

Это позволило добавить generics без отдельной виртуальной машины и без отказа от совместимости с ранее скомпилированными классами. Однако после стирания сигнатура метода родителя может отличаться от сигнатуры специализированного метода потомка, поэтому понадобился адаптер — bridge-метод.

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

Пусть интерфейс содержит метод, возвращающий T, а реализация для String объявляет метод, возвращающий String. На уровне исходного кода это корректное переопределение после подстановки типа.

После стирания интерфейс ожидает метод, возвращающий Object, а класс содержит метод, возвращающий String. Для JVM это разные дескрипторы методов, поэтому одной только реализации с результатом String недостаточно для корректного виртуального вызова через интерфейсную ссылку.

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

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

interface Box<T> {
    T get();
}

class StringBox implements Box<String> {
    public String get() {
        return "value";
    }
}

Box<String> box = new StringBox();
Object value = box.get();

В исходном коде StringBox.get() переопределяет Box<String>.get(). После стирания интерфейс фактически требует метод примерно с сигнатурой Object get(), тогда как реализация класса имеет String get().

Компилятор добавляет в StringBox синтетический bridge-метод с результатом Object. Он вызывает настоящий String get() и возвращает его результат как Object. Поэтому вызов через Box<String> сохраняет обычную динамическую диспетчеризацию.

Bridge-метод создаёт компилятор, а не JVM во время каждого вызова. В байткоде он обычно помечен флагами synthetic и bridge; исходный Java-код такой метод не показывает.

Механизм применяется не только к generics: bridge-методы могут поддерживать и переопределение с ковариантным возвращаемым типом. В случае параметров компилятор также может добавить необходимые приведения типов внутри bridge-метода.

Практическое следствие — у класса могут существовать два метода с одинаковым именем, но разными JVM-дескрипторами, хотя в исходном коде разработчик явно объявил только один. Это важно при использовании reflection, генерации прокси, инструментов AOP и анализе stack trace.

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

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

Можно отказаться от generics и использовать Object, но это ухудшит типобезопасность и перенесёт проверки типов во время выполнения. Можно написать ручной адаптер с отдельным методом, но это увеличит шаблонный код и риск ошибок при расширении иерархии.

Рациональный вариант — оставить обобщённый интерфейс и позволить компилятору создать bridge-метод. В результате клиент получает проверку типов на этапе компиляции, а вызовы через интерфейс корректно доходят до специализированной реализации.

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

Можно ли вызвать bridge-метод напрямую из исходного Java-кода?

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

Однако bridge-метод можно обнаружить через reflection: у объекта Method доступны признаки isBridge() и isSynthetic(). Инструменты, перебирающие методы рефлексией, должны учитывать такие методы, иначе они могут ошибочно посчитать один логический метод двумя разными операциями.

Создаёт ли bridge-метод второй независимый вариант логики?

Нет. Это короткий делегирующий адаптер, а не самостоятельная бизнес-реализация. Основная логика находится в методе потомка; bridge только обеспечивает совместимость JVM-дескрипторов и при необходимости выполняет приведение параметров или результата.

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

Что произойдёт, если объявление пользователя конфликтует с предполагаемым bridge-методом?

Компилятор может сообщить о name clash, если после стирания типов методы получают конфликтующие сигнатуры и не могут корректно сосуществовать. Это предотвращает ситуацию, в которой невозможно однозначно определить, какой метод должен обслуживать вызов через обобщённый или необобщённый тип.

Поэтому при проектировании обобщённых иерархий нужно учитывать не только исходные сигнатуры, но и их стёртые формы. Методы, выглядящие различными из-за параметров типов, после стирания могут оказаться одинаковыми для JVM.