Как компилятор учитывает в функциональном интерфейсе абстрактный метод с сигнатурой публичного метода Object?

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

Такой метод не учитывается при подсчёте единственного абстрактного метода функционального интерфейса. Поэтому интерфейс может объявить, например, собственный equals(Object) и при этом оставаться пригодным для лямбда-выражения, если у него есть ровно один другой абстрактный метод.

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

Функциональные интерфейсы появились в Java 8 как целевой тип для лямбда-выражений и ссылок на методы. При этом любой объект Java уже имеет публичные методы equals, hashCode и toString, унаследованные от Object.

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

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

Интерфейс может переобъявить equals(Object), чтобы зафиксировать часть своего контракта. Ошибочно считать, что это автоматически добавляет вторую абстрактную операцию и запрещает использование лямбда-выражений.

Однако исключение действует только для методов, совпадающих по сигнатуре с публичными методами Object. Любой дополнительный абстрактный метод, не относящийся к этому набору, нарушит требование функционального интерфейса и приведёт к ошибке при использовании @FunctionalInterface или лямбды.

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

Для определения функциональности Java рассматривает абстрактные методы интерфейса с учётом унаследованных методов. Абстрактные методы, совпадающие с публичными методами Object, не формируют единственный абстрактный метод функционального интерфейса.

Например, test(String) считается функциональным методом, а equals(Object) — нет:

@FunctionalInterface
interface Проверка {
    boolean test(String значение);
    boolean equals(Object другой);
}

Проверка п = строка -> строка.isBlank();

Лямбда реализует test, но не превращает тело лямбды в реализацию equals. Вызов equals у экземпляра лямбды не должен использоваться как вызов предиката: это отдельный метод объекта, а его конкретное поведение определяется правилами Object и реализацией лямбда-объекта.

Аналогично, переобъявление hashCode() или toString() само по себе не добавляет ещё один учитываемый абстрактный метод. Но интерфейс, содержащий только такие методы, не становится функциональным: после их исключения не остаётся единственного абстрактного метода.

Практическое следствие — добавление в функциональный интерфейс декларации equals, hashCode или toString не меняет его лямбда-совместимость. Добавление любого другого абстрактного метода меняет контракт и делает прежний интерфейс непригодным как целевой тип для лямбд.

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

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

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

Рациональное решение — оставить equals только при наличии реальной контрактной необходимости и отдельно документировать семантику сравнения. Для обычного предиката лучше ограничиться одним предметным методом: это сохраняет ясный API и не создаёт ложного ожидания, что лямбды сравниваются по логике test.

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

1. Станет ли интерфейс функциональным, если он объявляет только equals(Object)?

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

2. Вызывает ли тело лямбды метод equals, если интерфейс объявляет и test, и equals?

Нет. Тело лямбды соответствует единственному учитываемому абстрактному методу — в примере test. Вызов equals является отдельным вызовом метода объекта; он не передаёт аргумент в тело test и не выполняет его логику.

3. Почему добавление hashCode() или toString() также не нарушает функциональность интерфейса?

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