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

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

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

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

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

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

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

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

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

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

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

interface Document {
    default String format() { return "обычный"; }
}

interface Invoice extends Document {
    @Override
    default String format() { return "счёт"; }
}

interface PaidInvoice extends Invoice { }

class Report implements PaidInvoice { }

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

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

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

В библиотеке есть интерфейс Document с default-форматированием. Для счетов создаётся Invoice, которому требуется другой формат, а затем несколько специализированных интерфейсов расширяют Invoice, не меняя форматирование.

Можно переопределить метод в каждом конечном интерфейсе или классе. Такой вариант даёт локальный контроль, но приводит к дублированию и риску расхождения поведения. Другой вариант — переопределить default-метод только в Invoice и позволить дочерним интерфейсам его унаследовать.

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

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

Что произойдёт, если дочерний интерфейс объявит тот же метод как abstract?

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

Это позволяет интерфейсу намеренно отменить унаследованное поведение. Поэтому наличие default-метода у родителя не гарантирует, что любой потомок автоматически будет конкретным.
Кто победит, если класс наследует обычный метод от суперкласса и default-метод от интерфейса?

Приоритет имеет метод класса, включая унаследованный от суперкласса. Default-метод интерфейса не заменяет поведение, уже предоставленное классом.

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

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

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