Горячая вакансия – релокация в Берлин! Узнать подробности...
Горячая вакансия – релокация в Берлин! Узнать подробности...

Что если оба реализуемых интерфейса объявляют один и тот же метод?

Посмотреть в Telegram: @JavaSobes/95
Если объявление полностью одинаково – нет никакой проблемы, класс-реализация должен просто определить этот метод.

Когда у обоих интерфейсов объявлены методы с одинаковой сигнатурой, но разными возвращаемыми типами – всё зависит от того, какие именно эти типы.

Переопределение метода (override) еще с Java 5 ковариантно относительно возвращаемого типа. То есть, в наследнике тип результата метода может быть наследником: super метод возвращает Number, @Override метод возвращает Integer.

Если типы не связаны отношением наследования, например String и Long – такой класс невозможно реализовать.

Для примитивов никакой ковариантности возвращаемого типа нет. Даже если типы совместимы относительно присваивания: intlong, intInteger. В любом из таких случаев будет ошибка о несовместимости возвращаемых типов, для примитивов они должны совпадать в точности.

Если различие в части throws, методы объявлены выбрасывающими разные типы исключений. Правила здесь те же, что для возвращаемых типов – работает ковариантность. Отличие лишь в том, что исключений примитивных типов не бывает, а даже для не являющихся родителем и наследником исключений всегда есть вариант, удовлетворяющий обоим – отсутствие выбрасываемых исключений вообще.
Если метод дефолтный в обоих интерфейсах, то есть снабжен реализацией. Компилятору изначально понятно, что невозможно будет на момент вызова определить, какой метод реально подразумевался. Так что еще на объявлении класса-реализации компилятор выдаст ошибку «inherits unrelated defaults».

В таком случае в классе необходимо переопределить этот общий метод, и явно перенаправить вызов в нужную родительскую реализацию. Для этого есть синтаксис явного указания нужного базового интерфейса MyBase.super.doSmth(). См. пример ниже.

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

На практике с этой ситуацией можно столкнуться даже с классами стандартной библиотеки. Например, реализуя List и Set одним классом, вы получите эту ошибку для метода spliterator().

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

Других различий не бывает – изменение других модификаторов метода интерфейса недопустимо, а изменение списка параметров и имени делает его просто другим методом.