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

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

Лямбда не имеет самостоятельного типа до выбора целевого функционального интерфейса. Поэтому вывод типов и проверка лямбды выполняются совместно.

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

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

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

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

В лямбде можно не указывать тип параметра. Однако компилятор обязан знать этот тип, чтобы проверить операции внутри тела: вызовы методов, доступные преобразования и совместимость результата.

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

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

Рассмотрим обобщённый метод:

import java.util.function.Function;

class Demo {
    static <T, R> R convert(T value, Function<T, R> function) {
        return function.apply(value);
    }

    static String example() {
        return convert(Integer.valueOf(42), value -> value.toString());
    }
}

Из первого аргумента компилятор выводит T как Integer. Следовательно, второй параметр метода должен иметь вид Function<Integer, R>, поэтому параметр value лямбды получает статический тип Integer.

Из тела лямбды выводится результат типа String, поэтому R выводится как String. Дополнительно ожидаемый тип результата example ограничивает результат вызова типом, совместимым со String.

Механизм можно представить как последовательное формирование ограничений:

аргумент Integer задаёт ограничение для T;
сигнатура Function<T, R> превращается в целевой тип лямбды;
после подстановки T = Integer параметр лямбды получает тип Integer;
выражение тела лямбды формирует ограничения для R;
контекст присваивания или возврата может добавить ограничения для результата.

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

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

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

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

Вариант с явным параметром функционального интерфейса надёжнее при сложной перегрузке: например, заранее созданный Function<Integer, String> устраняет неоднозначность и делает контракт очевидным. Минус — больше кода и потеря краткости вызова.

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

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

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

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

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

Поэтому одна и та же форма лямбды может соответствовать разным интерфейсам, например функции, предикату или компаратору. Контекст вызова определяет, какой контракт будет проверяться.

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

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

Однако контекст не всегда выбирает единственный тип сам по себе. Если доступно несколько несовместимых вариантов или лямбда не даёт достаточных ограничений, компилятор сообщит об ошибке.

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

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

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