Метод интерфейса по умолчанию для абстрактного суперкласса

В текущем состоянии вашей программы, если бы вы переопределили A#foo в C.java (где метод по умолчанию возвращает true, а переопределенный метод возвращает false, печать C#foo привела бы к false, полностью игнорируя метод по умолчанию.

Любые абстрактные методы, определенные в абстрактном классе, должны быть переопределены первым конкретным классом, который расширяет абстрактный класс. По этой причине требуется, чтобы C.java переопределяло A#foo.

Методы по умолчанию в интерфейсах не требуется переопределять.

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

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

abstract class A {
    abstract boolean bar();
}

interface B {
    default boolean foo() { return doBlah(); }
}

class C extends A implements B {
    @Override
    public boolean foo() {
        ...
    }   

    @Override
    public boolean bar() {
        ...
    }
}

Если вы хотите переопределить только A#foo в некоторых случаях, вы можете просто полностью удалить абстрактный метод и сохранить метод по умолчанию в B.java и переопределить его в C.java:

abstract class A {

}

interface B {
    default boolean foo() { return doBlah(); }
}

class C extends A implements B {
    @Override
    public boolean foo() {
        ...
    }   
}

Если удаление A#foo невозможно, переименуйте метод по умолчанию, B#foo, во что-то другое.

abstract class A {
    abstract boolean foo();
}

interface B {
    default boolean bar() { return doBlah(); }
}

class C extends A implements B {
    @Override
    public boolean foo() {
        ...
    }   

    @Override
    public boolean bar() {
        ...
    }
}

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

В случае, который вы описываете, неясно, действительно ли метод по умолчанию в интерфейсе (который по замыслу должен был быть добавлен позже) действительно выполняет контракт, как первоначально предполагалось абстрактным классом.

В этом случае для Java безопаснее жаловаться.

Вышеприведенный текст является моей интерпретацией абзаца в 9.4.1.3. спецификации JLS SE8, и я цитирую:

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

Ответ Jacob G. вдохновил меня на это решение:

interface Z {
     abstract boolean foo();
}

abstract class A implements Z {

}

interface B extends Z {
     default boolean foo() { return doBlah(); }
}

class C extends A implements B {

}

Таким образом, все подклассы класса A должны определять метод foo(), не требуя, чтобы каждый класс, реализующий B, повторно реализовывал его.