Как мы в IntelliJ IDEA ищем лямбда-выражения

// MyFoo.java
import org.example.foo.*;
import org.example.bar.*;
import org.example.evilcompany.*; class MyFoo implements Foo {...}

Придется посмотреть на содержимое нескольких пакетов. Глядя только на файл, мы не можем понять, какое же настоящее полное имя Foo. Индексирование сильно затянется, если при анализе данного файла нам придется делать полноценное разрешение символа. А каждый пакет может быть определен в нескольких местах (к примеру, в нескольких jar-файлах). Ведь мы можем перенести описание интерфейса Foo, к примеру, из пакета org.example.foo в пакет org.example.bar, и ничего не менять в файле MyFoo.java, и при этом полное имя Foo изменится. Но основная проблема даже не в этом, а в том, что индекс, построенный по файлу MyFoo.java, будет зависеть не только от него, но и от других файлов.

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

Тогда помимо явных и анонимных наследников у нас появляются лямбда-выражения и ссылки на методы. Ситуация сильно меняется, когда класс, наследников которого мы ищем, является функциональным интерфейсом. Что же теперь положить в индекс, и что вычислять непосредственно при поиске?

Предположим, у нас есть функциональный интерфейс:

@FunctionalInterface
public interface StringConsumer { void consume(String s);
}

Например: В коде встречаются разные лямбда-выражения.

() -> {} // точно не подходит: нет параметров
(a, b) -> a + b // точно не подходит: два параметра
s -> { return list.add(s); // точно не подходит: возвращаем значение
}
s -> list.add(s); // может и подходит

Определить возвращаемый тип более точно обычно нельзя. То есть быстро мы можем отфильтровать только те лямбды, у которых неподходящее количество параметров либо очевидно неподходящий возвращаемый тип, например void против не-void. Все это долго и потребует завязки на содержимое других файлов. Скажем, в лямбде s -> list.add(s) для этого надо выполнить разрешение символов list и add, а, возможно, и запустить полноценную процедуру вывода типов.

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

Да, иногда это работает. Возможно, стоит посмотреть вокруг лямбды, чтобы что-то понять? Например:

// объявление локальной переменной или поля другого типа
Predicate<String> p = s -> list.add(s); // возврат из метода другого типа
IntPredicate getPredicate() { return s -> list.add(s);
} // присваивание локальной переменной другого типа
SomeType fn;
fn = s -> list.add(s); // приведение к другому типу
foo((SomeFunctionalType)(s -> list.add(s))); // объявление массива другого типа
Foo[] myLambdas = {s -> list.add(s), s -> list.remove(s)};

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

list.stream() .filter(s -> StringUtil.isNonEmpty(s)) .map(s -> s.trim()) .forEach(s -> list.add(s));

Программисту ясно, что никакая. Какая из этих трех лямбд может иметь тип StringConsumer? Потому что очевидно, что здесь у нас цепочка Stream API, а там только функциональные интерфейсы из стандартной библиотеки, нашего типа там быть не может.

А дальше что? В итоге получается, что мы у индекса можем запросить список всех Java-файлов, где используются лямбды с нужным числом параметров и допустимым возвращаемым типом (на самом деле мы отслеживаем только четыре варианта: void, не-void, boolean и любой). Тогда в большом проекте вы не дождетесь списка всех реализаций интерфейса, даже если их будет всего две. Для каждого из этих файлов строить полное дерево PSI (это вроде дерева разбора, но с разрешением символов, выводом типов и другими умными штуками) и честно выполнять вывод типа для лямбды?

Получается, нам надо проделать следующие шаги:

• Спросить у индекса (дешево)
• Построить PSI (дорого)
• Вывести тип лямбды (очень дорого)

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

static <T> void doSmth(Class<T> aClass, T value) {}

Тогда тип лямбды выведется как T, и подставлять все равно придется. Этот метод можно вызвать вот так: doSmth(Runnable.class, () -> {}). Поэтому тут сэкономить получается, но не больше 10%. Но это редкий случай. Кардинально проблема не решается.

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

• Переменная list → тип java.util.List
• Метод List.stream() → тип java.util.stream.Stream
• Метод Stream.filter(...) → тип java.util.stream.Stream, на аргументы filter даже не смотрим, какая разница
• Метод Stream.map(...) → тип java.util.stream.Stream, аналогично
• Метод Stream.forEach(...) → есть такой метод, его параметр имеет тип Consumer, который, очевидно, не StringConsumer.

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

CompletableFuture.supplyAsync(Foo::bar, myExecutor).thenRunAsync(s -> list.add(s));

Здесь мы можем легко понять, что

• Методов CompletableFuture.supplyAsync имеется два, но один принимает один аргумент, а второй — два, поэтому выбираем тот, который принимает два. Он возвращает CompletableFuture.
• Методов thenRunAsync тоже два, и из них можно аналогичным образом выбрать тот, который принимает один аргумент. Соответствующий параметр имеет тип Runnable, значит это не StringConsumer.

Но часто это тоже не страшно. Если же несколько методов принимают одинаковое количество параметров, либо некоторые имеют переменное число параметров и тоже выглядят подходящими, то придется отслеживать все варианты. Например:

new StringBuilder().append(foo).append(bar).chars().forEach(s -> list.add(s));

• new StringBuilder() очевидно создает java.lang.StringBuilder. Для конструкторов мы все-таки разрешаем ссылку, но сложный вывод типов здесь не требуется. Даже если бы было new Foo<>(x, y, z), мы не выводим значения типовых параметров, нам интересен только Foo.
• Методов StringBuilder.append, принимающих один аргумент, очень много, но все они возвращают тип java.lang.StringBuilder, поэтому нам неважно, какого там типа foo и bar.
• Метод StringBuilder.chars один и возвращает java.util.stream.IntStream.
• Метод IntStream.forEach один и принимает тип IntConsumer.

Например, тип лямбды, переданной в ForkJoinPool.getInstance().submit(...), может быть Runnable или Callable, но если мы ищем что-то третье, то все еще можем отбросить эту лямбду. Даже если где-то остается несколько вариантов, можно отслеживать их все.

Тогда процедура ломается и приходится запускать полный вывод типов. Неприятная ситуация возникает, когда метод возвращает generic-параметр. Он хорошо проявляется на моей библиотеке StreamEx, в которой есть абстрактный класс AbstractStreamEx<T, S extends AbstractStreamEx<T, S>>, содержащий методы вроде S filter(Predicate<? Впрочем, один случай мы поддержали. Обычно люди работают с конкретным классом StreamEx<T> extends AbstractStreamEx<T, StreamEx<T>>. super T> predicate). В данном случае можно выполнить подстановку параметра типа и узнать, что S = StreamEx.

Но мы ничего не сделали с построением PSI. Отлично, мы во многих случаях избавились от очень дорогого вывода типов. Вернемся к нашему стриму: Как-то обидно делать синтаксический разбор файла на пятьсот строк только ради того, чтобы выяснить, что лямбда в строке 480 не подходит под наш запрос.

list.stream() .filter(s -> StringUtil.isNonEmpty(s)) .map(s -> s.trim()) .forEach(s -> list.add(s));

Соответственно, в индекс для последней лямбды мы можем положить следующую информацию: Если list — это локальная переменная, параметр метода или поле в текущем классе, то уже на этапе индексирования мы можем найти ее объявление и установить, что короткое имя типа —
List.

Тип сей лямбды есть тип параметра метода forEach от одного аргумента, вызванного на результате метода map от одного аргумента, вызванного на результате метода filter от одного аргумента, вызванного на результате метода stream от нуля аргументов, вызванного у объекта типа List.

Тогда мы сразу не сдаемся и пытаемся снова начать с глобального поиска на следующем методе цепочки. Возможны варианты, что глобальный поиск окажется слишком дорог (в проекте много классов List), либо начало цепочки не разрешается в контексте одного файла (скажем, это поле родительского класса), либо где-то цепочка прервется, потому что метод возвращает generic-параметр. Например, для цепочки map.get(key).updateAndGet(a -> a * 2) в индекс легла следующая инструкция:

Тип сей лямбды есть тип единственного параметра метода updateAndGet, вызванного на результате метода get с одним параметром, вызванного на объекте типа Map.

К примеру, вы ищете реализации функционального интерфейса, их всего три штуки в проекте, а IntelliJ IDEA их ищет десять секунд. Удивительно, что это яркий пример фичи, которая со временем сама начинает работать медленнее. И проект у вас хоть и огромный, но за три года вырос, может, процентов на пять. А вы прекрасно помните, что три года назад их было тоже три, вы их тоже искали, но тогда среда выдавала ответ за две секунды на этой же машине. Руки бы поотрывать этим горе-программистам. Конечно, вы начинаете справедливо негодовать, чего там эти разработчики напортили, что IDE стала так жутко тормозить.

Может быть поиск работает так же, как три года назад. А мы, может быть, вообще ничего не меняли. А теперь ваши коллеги превратили анонимные классы в лямбды, стали активно использовать стримы или подключили какую-нибудь реактивную библиотеку, в результате лямбд стало не сто, а десять тысяч. Просто три года назад вы только перешли на Java 8, и у вас в проекте было, скажем, всего сто лямбд. И теперь, чтобы откопать три нужные лямбды, IDE надо перерыть в сто раз больше.

Но тут приходится грести даже не против течения, а вверх по водопаду. Я сказал «может быть», потому что, естественно, мы время от времени возвращаемся к этому поиску и пытаемся его ускорить. Мы стараемся, но количество лямбд в проектах растет очень быстро.