Рубрики
Без рубрики

Реактивный набор инструментов: Почему и как

Манифест Реактивного инструментария. С тегами java, новички, программирование.

Более года назад я начал работать над Реактивным набором инструментов . Это все еще больше исследование, чем что-то практически полезное. Тем не менее, недавний прогресс в реализации дает мне надежду на то, что существует решение многих долгосрочных проблем в разработке Java.

Почему?

Все последнее десятилетие для разработки Java – странное время.

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

С другой стороны, повседневная разработка Java претерпела довольно небольшие изменения. Мы все еще используем медленную и раздутую пружину, просто переключились с XML на аннотации. Мы все еще боремся с NPE, используя исключения как часть бизнес-логики и записывая выражения AOP внутри текстовых констант. Мы все знаем, что это плохая практика, в конце концов, отличная “Эффективная Java” Джошуа Блоха – это книга, известная каждому программисту Java. Мы все еще откладываем переход на более поздние версии Java, потому что наши фреймворки и библиотеки плохо с ними работают. Мы смешиваем и сопоставляем Java-фреймворки и библиотеки для создания наших приложений, и хотя это позволяет нам создавать приложения достаточно быстро, в большинстве случаев мы едва знаем, что происходит под капотом. Например, знаете ли вы, сколько потоков запустилось при запуске приложения Spring Boot?

Трудно сказать, что мы не знаем о том, как писать код по-другому. Количество публикаций об альтернативных подходах просто огромно или Серия статей Нила Форда .g (например, посмотрите на блог Джона Макклина или блог Пьера-Ива Сомона

Итак, в чем проблема, почему мы все еще используем неэффективные структуры и подходы каменного века?

Я думаю, что есть несколько факторов.

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

Второй – это страх не быть в тренде. Молодые разработчики Java особенно часто чувствуют это. И поскольку из каждой дыры они слышат весенний шум, они считают, что нет другого способа написать Java “облачный родной” (что, черт возьми, это значит?) программное обеспечение. Ведь “никто не был уволен за то, что выбрал Весну”.

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

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

Как

Конечно, Reactive Toolbox – это не первая попытка изменить способ написания кода Java. Используемые методы и подходы также не новы – в основном они основаны на хорошо известных идеях функционального программирования (для краткости именуемых ниже FP ). Но есть несколько вещей, которые, я считаю, делают Reactive Toolbox (ниже RT для краткости) другим:

  • RT очень прагматичен и ориентирован на практическое использование. Он не привносит много “сленга” FP и не пытается заставить пользователя сначала изучить концепции и идеи FP или теории категорий.
  • RT не идет на компромиссы с существующим кодом, даже со стандартной библиотекой времени выполнения Java. Код, который плохо сочетается с подходами RT, заменяется или оборачивается. К сожалению, такого кода слишком много, так что впереди очень долгий путь. К счастью, это дает уникальный шанс отказаться от устаревших API и, наконец, прекратить их использование – то, что мы должны были сделать десять лет назад.
  • RT является Реактивным Набор инструментов: асинхронное и параллельное выполнение кода наряду с высокой производительностью асинхронный Ввод-вывод лежит в основе структуры.

Наконец, RT использует соглашение, которое упрощает обработку нулевых значений:

  • Все значения, которые не должны быть null представлены простыми типами.
  • Все значения, которые могут отсутствовать, представлены типами, заключенными в Параметр . Эта конвенция применяется повсеместно, поэтому Опция может присутствовать в параметрах метода и полях класса. Обратите внимание, что это противоречит “лучшим практикам”, которые ограничивают использование Необязательного только для возврата значений и, следовательно, полностью устраняют все преимущества , предоставляемые этим драгоценным камнем, находящимся в стандартной библиотеке Java начиная с Java 8.

Давайте заглянем глубже: Прагматичный Функциональный Java

Как упоминалось выше, RT ориентирован на практическое использование, а не на теоретическую чистоту или согласие с традиционным сленгом или подходами FP.

API Reactive Toolbox полностью устраняет исключения и использует выделенный тип – Результат – для обработки и распространения информации об ошибках. Подход описан здесь более подробно.

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

Аналогичный подход используется с базовым асинхронным примитивом – Обещание . Он имеет встроенную обработку ошибок (с тем же типом Result ) вместо того, чтобы быть контейнером общего назначения. Опять же, он обменивает общность на краткость и читабельность. И даже больше для удобства.

Будучи смешанными вместе, эти методы позволяют писать очень лаконичный и выразительный код. Наряду с самыми последними версиями Java (на момент написания, Java 14 с включенными функциями предварительного просмотра) полученный код едва ли длиннее аналогичного кода, написанного в Котлине, развенчивая миф о многословии Java.

Давайте посмотрим глубже: Асинхронная обработка и ввод-вывод

Обещания в RT является основным примитивом для работы с асинхронными задачами и выполнения асинхронного ввода-вывода. Доступ к планировщику задач и операциям ввода-вывода низкого уровня, предоставляемым как часть API Promise.

Реализация асинхронного ввода-вывода в RT основана на самом продвинутом API асинхронного ввода-вывода, представленном в последних версиях ядер Linux//io_uring .

Это служит сразу нескольким целям:

  • Подавляющему большинству приложений не нужен никакой другой исполнитель, кроме того, который предоставлен RT. Нет необходимости в ручной настройке/настройке/управлении/синхронизации/и т.д.
  • Единый согласованный низкоуровневый API для все Операции ввода-вывода, от открытия файла или сокета до чтения/записи/статистики/копирования и закрытия.
  • Асинхронное выполнение на основе обещаний не требует синхронизации на уровне приложения. Просто напишите код, как для однопоточного приложения!

Недостатки Принятого Подхода

Как упоминалось выше, RT не идет на компромиссы в отношении совместимости существующего кода (включая стандартную библиотеку) с моделью RT. Это делает огромное количество существующего кода бесполезным и часто требует упаковки или переписывания с нуля даже некоторых довольно простых вещей, таких как синтаксический анализ чисел из строки.

И главное ограничение на данный момент: как упоминалось выше, RT использует API, который доступен в самых последних ядрах Linux. Это означает, что RT не работает в Windows или macOS, а также в ядрах Linux до версии 5.6. На момент написания эти ядра еще не являются частью стандартных дистрибутивов, и для того, чтобы даже поэкспериментировать с RT, потребуется установить новое ядро.

Оригинал: “https://dev.to/siy/reactive-toolbox-why-and-how-138”