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

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

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

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

Для этого подинтерфейс может переобъявить унаследованный метод без default. Такой метод становится абстрактным требованием именно для подинтерфейса, поэтому автоматическое поведение родительского интерфейса больше не применяется.

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

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

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

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

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

interface Audit {
    default void record() { }
}

interface StrictAudit extends Audit {
    void record();
}

class Service implements StrictAudit {
    @Override
    public void record() {
        System.out.println("explicit audit");
    }
}

В этом примере Service не может просто унаследовать тело Audit.record(): StrictAudit объявил метод абстрактным. Метод реализации должен быть public, поскольку методы интерфейса имеют публичный контракт.

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

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

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

В библиотеке есть интерфейс Exporter, где метод export() имеет default-реализацию для простого формата. Для финансовых экспортёров вводят RegulatedExporter, потому что каждый такой экспортёр обязан добавлять контрольную информацию и вести аудит.

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

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

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

Может ли абстрактный класс реализовать такой подинтерфейс без тела метода?

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

Да, если суперкласс предоставляет совместимый конкретный экземплярный метод. Правило разрешения методов учитывает реализацию класса: она может удовлетворить абстрактному требованию интерфейса. При этом метод должен иметь допустимую видимость и совместимую сигнатуру; закрытый метод суперкласса такое требование не удовлетворяет.
Можно ли в классе вызвать отменённый default-метод родительского интерфейса через Interface.super?

Нет, если подинтерфейс переобъявил этот метод как абстрактный. Для обращения к Interface.super интерфейс должен предоставлять допустимый унаследованный default-метод в текущем контексте. После абстрактного переобъявления подинтерфейс намеренно устраняет такой вариант поведения, поэтому класс должен выбрать или определить собственную реализацию.