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

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

interface Auditable { void audit(); }
interface Identified { String id(); }

static <T> T choose(boolean first, T a, T b) {
    return first ? a : b;
}

static <T extends Auditable & Identified> void inspect(T value) {
    value.audit();
    value.id();
}

class A implements Auditable, Identified {
    public void audit() {}
    public String id() { return "A"; }
}

class B implements Auditable, Identified {
    public void audit() {}
    public String id() { return "B"; }
}

inspect(choose(true, new A(), new B()));

В последнем вызове компилятор может вывести для T общий тип, включающий Auditable и Identified. Этот тип не обязан быть объявленным классом или интерфейсом.

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

Generics появились в Java, чтобы объединить повторное использование алгоритмов с проверкой типов на этапе компиляции. Без них общий метод должен был бы принимать Object, а клиентский код — выполнять небезопасные приведения.

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

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

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

Небезопасное приведение решает проблему лишь внешне: оно переносит проверку на время выполнения и может привести к ClassCastException. Требуется выразить ограничение средствами системы типов, не создавая искусственный объединяющий класс.

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

При выводе типа компилятор ищет тип, совместимый со всеми ограничениями вызова. Для нескольких аргументов он анализирует их наиболее конкретный общий супертип — least upper bound. Если общими являются несколько интерфейсов, результат может быть представлен как intersection type, например Auditable & Identified.

Такой тип существует прежде всего внутри анализа компилятора. Разработчик не обязан объявлять интерфейс AuditableAndIdentified, чтобы вызвать метод с ограничением T extends Auditable & Identified.

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

Есть ограничения. Если у типов нет совместимого общего супертипа или ограничения противоречат друг другу, вывод завершается ошибкой. Кроме того, конкретный класс в пересечении должен занимать допустимое положение, а Java не позволяет произвольно объединять несовместимые классы.

Во время выполнения отдельный intersection type не сохраняется как самостоятельный runtime-тип. Для параметров типа действует стирание: при наличии нескольких границ первой обычно становится граница-класс, а если её нет — первый интерфейс. Остальные границы используются компилятором для проверки операций.

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

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

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

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

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

Вопрос: Является ли пересечение типов новым классом, создаваемым JVM?

Ответ: Нет. Это конструкция системы типов, используемая компилятором для описания ограничений. JVM работает с обычным объектом его реального класса, а после стирания параметр типа заменяется первой границей или Object при отсутствии границ.
Вопрос: Можно ли получить пересечение двух произвольных классов?

Ответ: Нет. Java допускает не более одного класса в цепочке границ параметра типа, а остальные границы должны быть интерфейсами. Два независимых конкретных класса нельзя объявить как совместное ограничение, поскольку объект не может одновременно наследоваться от двух классов.
Вопрос: Обязан ли результат вывода всегда иметь имя, которое можно написать в исходном коде?

Ответ: Нет. Компилятор может использовать невыразимый, или non-denotable, тип, включая пересечение типов и некоторые захваченные wildcard-типы. Разработчик работает с ним косвенно: доступ получает только к членам, гарантированным его ограничениями, а наружу такой тип обычно проявляется через объявленный параметр метода или целевой тип.