Если объявление полностью одинаково – нет никакой проблемы, класс-реализация должен просто определить этот метод.
Когда у обоих интерфейсов объявлены методы с одинаковой сигнатурой, но разными возвращаемыми типами – всё зависит от того, какие именно эти типы.
Переопределение метода (override) еще с Java 5
ковариантно относительно возвращаемого типа. То есть, в наследнике тип результата метода может быть наследником:
super метод возвращает
Number,
@Override метод возвращает
Integer.
Если типы не связаны отношением наследования, например
String и
Long – такой класс
невозможно реализовать.
Для примитивов никакой ковариантности возвращаемого типа нет. Даже если типы
совместимы относительно присваивания:
int→
long,
int→
Integer. В любом из таких случаев будет ошибка о несовместимости возвращаемых типов,
для примитивов они должны совпадать в точности.
Если различие в части throws, методы объявлены выбрасывающими разные типы исключений. Правила здесь те же, что для возвращаемых типов – работает ковариантность. Отличие лишь в том, что исключений примитивных типов не бывает, а даже для не являющихся родителем и наследником исключений всегда есть вариант, удовлетворяющий обоим – отсутствие выбрасываемых исключений вообще.
Если метод дефолтный в обоих интерфейсах, то есть снабжен реализацией. Компилятору изначально понятно, что невозможно будет на момент вызова определить, какой метод реально подразумевался. Так что еще на объявлении класса-реализации компилятор выдаст ошибку «inherits unrelated defaults».
В таком случае в классе необходимо переопределить этот общий метод, и явно перенаправить вызов в нужную родительскую реализацию. Для этого есть синтаксис явного указания нужного базового интерфейса
MyBase.super.doSmth(). См. пример ниже.
Ошибка появится даже в случае, когда реализации полностью совпадают. Если бы компилятор такое позволял, нельзя было бы безопасно изменить и перекомпилировать только одну из реализаций.
На практике с этой ситуацией можно столкнуться даже с классами стандартной библиотеки.
Например, реализуя
List и
Set одним классом, вы получите эту ошибку для метода
spliterator().
Если в хоть одном из интерфейсов-предков метод
не имеет дефолтной реализации, ошибка компиляции будет предлагать альтернативное решение – сделать класс абстрактным. Добавление ключевого слова
abstract вернет вас в ту же неоднозначную ситуацию, и на ту же первоначальную ошибку.
Других различий не бывает – изменение других модификаторов метода интерфейса недопустимо, а изменение списка параметров и имени делает его просто другим методом.
