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

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

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

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

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

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

Рассмотрим обобщённый родительский класс с методом, принимающим T, и наследника, где T заменён на String. Для исходного кода это обычное переопределение метода.

После стирания в родительском классе метод принимает Object, а метод наследника — String. Если оставить только метод String, вызов через ссылку родительского типа не сможет найти корректную реализацию: JVM сопоставляет методы по имени и дескриптору, а не по исходному параметру типа.

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

Компилятор добавляет в наследник синтетический метод с erased-сигнатурой родителя. Этот метод является точкой полиморфного вызова: принимает Object, приводит его к String и вызывает специализированный метод String.

class Box<T> {
    void put(T value) { }
}

class StringBox extends Box<String> {
    @Override
    void put(String value) {
        System.out.println(value.length());
    }
}

Box<String> box = new StringBox();
box.put("Java");

Логически компилятор обеспечивает поведение, эквивалентное наличию в StringBox метода put(Object), который делегирует в put(String). Такой метод обычно помечается как synthetic и bridge и не является дополнительным API, предназначенным для непосредственного использования разработчиком.

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

Bridge-методы также важны для методов с ковариантными возвращаемыми типами: если после стирания возвращаемые типы требуют разных JVM-дескрипторов, компилятор может создать дополнительный делегирующий метод. При анализе reflection, stack trace или профиля это иногда приводит к появлению методов, которых нет непосредственно в исходном коде.

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

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

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

Вариант с bridge-методами позволяет оставить типобезопасное переопределение на уровне исходного кода. Компилятор сам создаёт адаптацию для JVM, а выбранное решение сохраняет обычный полиморфный вызов через базовый тип; цена — наличие синтетических методов, которые нужно учитывать при низкоуровневом анализе байткода и reflection.

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

Bridge-метод вызывается вместо переопределённого метода?

Да, при вызове через стёртый тип JVM может фактически попасть в bridge-метод. Но bridge — это не альтернативная бизнес-реализация, а автоматически созданный адаптер: он приводит аргумент или возвращаемое значение и передаёт управление настоящему переопределённому методу.

Создаётся ли bridge-метод для каждого переопределения обобщённого метода?

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

Можно ли считать bridge-метод частью публичного API класса?

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