Темная сторона лямбда-выражений в Java 8

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

Вторая самая большая особенность (в зависимости, конечно, от того, кого вы спрашиваете) — это Nashorn — новый движок JVM JavaScript, который должен привести Java в соответствие с другими движками JS, такими как V8 и его контейнер node.js.

Но эти новые функции имеют темную сторону к ним.

Я объясню. Платформа Java состоит из двух основных компонентов. JRE, который JIT компилирует и выполняет байт-код, и JDK, который содержит инструменты dev и компилятор исходного кода javac. Эти два компонента довольно (но не полностью) отделены друг от друга, что позволяет людям писать свои собственные языки JVM, и Scala стала популярной в последние несколько лет. И в этом заключается некоторая проблема.

JVM была разработана, чтобы быть независимой от языка в том смысле, что она может выполнять код, написанный на любом языке, при условии, что он может быть преобразован в байт-код. Сама спецификация байт-кода полностью OO, и была разработана, чтобы близко соответствовать языку Java. Это означает, что байт-код, скомпилированный из исходного кода Java, будет очень похож на него структурно

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

Когда вы смотрите на полностью динамические языки, такие как JavaScript , это расстояние становится огромным.

И теперь с Java 8 это начинает распространяться и на Java.

Так почему я должен заботиться?

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

Чтобы увидеть, как давайте (повторно) посетить пример ниже.

Java 6 & 7

Это традиционный метод, с помощью которого мы будем перебирать список строк, чтобы отобразить их длину.

Это вызовет исключение, если передается пустая строка. Трассировка стека будет выглядеть так:

Здесь мы видим соотношение 1: 1 между трассировкой стека, которую мы видим, и кодом, который мы написали, что делает отладку этого стека вызовов довольно простой. Это то, к чему привыкли большинство разработчиков Java.

Теперь давайте посмотрим на Scala и Java 8.

Scala

Давайте посмотрим на тот же код в Scala. Здесь у нас есть две большие перемены. Первое — это использование лямбда-выражения для отображения длин, а второе — итерация выполняется структурой (т. Е. Внутренняя итерация).

Здесь мы действительно начинаем замечать разницу между тем, как выглядит код, который вы написали, и тем, как JVM (и вы) увидят его во время выполнения. Если выдается исключение, стек вызовов на порядок длиннее , и его гораздо сложнее понять.

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

Это долго было проблемой со Scala, и одной из причин, по которой мы создали Scala Stackifier .

А теперь в Java 8

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

Это становится очень похоже на Scala. Мы платим цену за более короткий и краткий код с более сложной отладкой и более длинными синтетическими стеками вызовов.

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

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

JavaScript в Java 8

Java 8 представляет совершенно новый компилятор JavaScript. Теперь мы можем эффективно и просто интегрировать Java + JS. Однако нигде нет диссонанса между кодом, который мы пишем, и кодом, который мы отлаживаем, больше, чем здесь.

Вот та же самая функция в Nashorn —

В этом случае код байт-кода динамически генерируется во время выполнения с использованием вложенного дерева лямбда-выражений. Существует очень небольшая корреляция между нашим исходным кодом и результирующим байт-кодом, выполняемым JVM. Стек вызовов теперь на два порядка длиннее . В острых словах Mr.T — мне жаль дураков, которым нужно будет отлаживать стек вызовов, который вы здесь получите.

Вопросы, комментарии? (при условии, что вы можете прокрутить весь путь ниже этого стека вызовов). Дайте мне знать в разделе комментариев.