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

Java не выбирает произвольно один из конфликтующих default-методов. Если класс получает одинаковые default-методы от двух независимых интерфейсов, он должен явно переопределить метод; иначе конкретный класс не сможет корректно реализовать интерфейсы.

Автоматическое разрешение возможно, если один интерфейс является более специфичным наследником другого: тогда приоритет получает default-метод дочернего интерфейса. Метод класса или суперкласса также имеет приоритет над default-методом интерфейса.

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

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

Однако множественное наследование интерфейсов создаёт неоднозначность: разные интерфейсы могут предоставить методы с одинаковой сигнатурой, но разной логикой. Поэтому Java определяет правила приоритета и требует явного выбора там, где автоматический выбор был бы небезопасен.

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

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

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

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

Правила разрешения можно свести к следующему:

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

Минимальный пример:

interface Audit {
    default String source() { return "audit"; }
}

interface Metrics {
    default String source() { return "metrics"; }
}

class Service implements Audit, Metrics {
    @Override
    public String source() {
        return Audit.super.source();
    }
}

Класс Service явно разрешает конфликт и выбирает реализацию Audit. Вызов через ссылку типа Audit или Metrics не отменяет этого выбора: для объекта Service используется его переопределение, поскольку метод класса имеет приоритет.

Вызов вида Audit.super.source() разрешён для непосредственного суперинтерфейса класса. Нельзя использовать такой синтаксис как произвольный способ обратиться к любой реализации из цепочки интерфейсного наследования.

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

Главный компромисс — дополнительный код в классе против предсказуемости. Явное переопределение требует решить, какую семантику сохранить, объединить ли реализации или полностью написать новую; зато изменение набора интерфейсов не приводит к неявному изменению поведения.

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

В платформе обработки платежей класс одновременно реализует интерфейсы Auditable и Observable. Оба предоставляют default-метод с одинаковой сигнатурой, но один формирует запись для аудита, а другой отправляет техническую метрику. Простое добавление второго интерфейса приводит к конфликту компиляции.

Рассматривались варианты:

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

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

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

Меняет ли тип ссылки выбор default-метода при конфликте?

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

Можно ли вызвать default-реализацию интерфейса через имя интерфейса у обычного объекта?

Нет, специальный вызов default-реализации выполняется через форму Интерфейс.super.метод() внутри реализации класса. Обычный вызов через объект использует виртуальное разрешение метода и может привести к переопределению в классе, а не к принудительному обходу этого переопределения.

Что произойдёт, если позже один из интерфейсов станет наследником другого?

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