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

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

Лямбда не имеет самостоятельного типа до выбора контекста вызова. Поэтому результат зависит не от типа объекта во время выполнения, а от статического анализа аргументов и сигнатур перегруженных методов.

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

До появления лямбда-выражений аргумент обычно уже имел объявленный тип, поэтому компилятор мог сравнивать его с параметрами перегруженных методов. В Java 8 лямбды добавили функциональный стиль, но сохранили статическую типизацию.

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

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

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

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

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

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

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

import java.util.function.Consumer;
import java.util.function.Function;

class Api {
    static void use(Consumer<String> c) {}
    static void use(Function<String, Integer> f) {}

    static void demo() {
        // use(s -> s.length()); // неоднозначно
        use((Function<String, Integer>) (s -> s.length()));
    }
}

В первом вызове лямбда совместима с Function<String, Integer> как функция, возвращающая длину строки, но вызов метода также может рассматриваться в контексте Consumer<String>, поскольку вызов метода является допустимым телом действия. Ни одна перегрузка не оказывается однозначно более специфичной.

Явное приведение к функциональному интерфейсу задаёт целевой тип и устраняет неопределённость. Альтернативы — передать заранее типизированную переменную, использовать явно типизированный параметр лямбды или изменить API так, чтобы перегрузки не конкурировали за один и тот же вызов.

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

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

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

Рассматривались три варианта. Можно было оставить перегрузки и требовать от пользователей явного приведения: это минимальное изменение, но ухудшает читаемость вызовов. Можно было переименовать методы: решение делает API понятнее, однако создаёт несовместимость с уже существующим кодом. Можно было принимать единый объект-обработчик, но это усложняет модель типов и переносит различия в тело обработчика.

Выбранным решением стало явное приведение в нескольких неоднозначных местах и документирование целевого функционального интерфейса. Для нового API предпочтительнее разные имена операций, если их семантика различается: это уменьшает хрупкость клиентского кода при дальнейшем расширении набора перегрузок.

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

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

Нет. Лямбда не выполняется во время разрешения перегрузки, поэтому фактическое значение результата недоступно. Учитывается только совместимость тела лямбды с возвращаемым типом целевого функционального интерфейса.

Например, строковое значение, которое реально возвращается из тела, не заставляет Java автоматически предпочесть конкретную перегрузку, если тело допустимо и в другом контексте. Для устранения неоднозначности нужен явный целевой тип.

Поможет ли явное указание типа параметра лямбды всегда устранить неоднозначность?

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

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

Почему метод-ссылка может быть неоднозначной по той же причине?

Метод-ссылка также не имеет полностью определённого типа сама по себе. Её форма проверяется в контексте целевого функционального интерфейса: один контекст может трактовать ссылку как действие, другой — как функцию с результатом.

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