Jdbi и система модульной системы платформы Java (JPMS)

JPMS была введена в Java 9 как решение проблемы "jar hell", которая существовала с проектами, помещающими части на путь классов и надеясь, что JVM сможет правильно загрузить нужные вещи в нужный момент.

JPMS имеет своих сторонников и значительную критику (например, https://blog.joda.org/2bk/2017/05/java-se-9-jpms-automatic-modules.html), но это уже другой вопрос. Java включила её в состав платформы, и ожидают, что библиотеки начнут использовать её.

Общее положение дел (на версии 3.40.1)

Jdbi ввела базовую модульную структуру в 2019 году (см. https://github.com/jdbi/jdbi/issues/812) и начала выпускать базовую поддержку JPMS модулей (с автоматическими именами модулей) с версии 3.7.1.

Выпуск автоматических имен модулей достаточно для того, чтобы позволить другим проектам и библиотекам объявлять зависимости от артефактов Jdbi. Jdbi использует org.jdbi.v3.<...> как автоматические имена модулей. Имея автоматические имена модулей для всех артефактов, Jdbi избегает создания ненадёжных(dummy) имен модулей JVM из имён jar'ов.

Предупреждения сборки, такие как src/main/java/module-info.java:[14,16] module name component v3 should avoid terminal digits, будут здесь всегда. Эти предупреждения раздражающие, но не критичные.

Документация Javadoc

С выпуска плагина maven-javadoc-plugin 3.6.0, мы можем снова строить javadoc без использования JPMS, используя Java 11 (нашей версией выпуска) и больше не получаем предупреждений.

Перспективно, хотя возможно создание javadoc для каждого модуля Maven, структурированных как javadoc Java 9+, сборка агрегированной версии (все javadoc в одном месте) постоянно проваливалась.

Для агрегированных jar'ов, способ вызова плагином maven-javadoc инструмента javadoc не работает ("слишком много исправленных модулей") или ограничения плагина maven-javadoc-plugin (см. https://issues.apache.org/jira/browse/MJAVADOC-768, не решено).

Кроме того, сам инструмент javadoc плохо работает с автоматическими модулями (опция --module-source-path работает только с модульными описаниями, поэтому исправление модуля с исходным кодом является единственным жизнеспособным вариантом).

Полная модульная структура

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

Зависимости на основе имени файла

У Jdbi большое количество внешних зависимостей. Преобразование проекта к JPMS следует делать "снизу вверх" [https://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html], чтобы избежать "module hell".

Модули JPMS имеют три вида:

• модули с модульными описаниями. В зависимости от таких модулей хорошо и они окажутся на пути модулей.
• модули с автоматическим именем модуля в манифесте. В зависимости от таких модулей допустимо, так как их имя модуля стабильно и было установлено намеренно.
• всё остальное. Имена модулей для этих jar'ов устанавливаются по имени файла. Эти модули нестабильны (люди могут добавить записи манифеста или модульные описания с другим именем модуля. В зависимости от таких модулей и публикация их общедоступно - риск. Maven фактически предупреждает об этом:

[INFO] --- compiler:3.11.0:compile (default-compile) @ jdbi3-testing ---
[WARNING] *************************************************************************************************************************************************
[WARNING] * Required filename-based automodules detected: [otj-pg-embedded-1.0.1.jar]. Please don't publish this project to a public artifact repository! *
[WARNING] *************************************************************************************************************************************************

Необходимо потратить больше времени на анализ этих зависимостей.

Создание Jdbi с поддержкой JPMS

Jdbi в его текущем виде служит нашим пользователям хорошо. Введение JPMS должно не нарушить это и не сделать процесс разработки сложным.

Ясные требования для этого перехода:

• Сохранение структуры Maven "основной артефакт" / "тестовый артефакт" с теми же пакетами для каждого модуля Maven. Это позволяет использовать видимость пакета для экспонирования тестового кода и не загрязнять открытый API.
• Возможность использования "тестовых артефактов" в других модулях Maven таким же образом, как сейчас. Изменение базы кода для адаптации к JPMS следует избегать.
• Разрешение использования предоставленных и опциональных зависимостей в графе зависимостей Maven. Описание модулей должно уметь работать с опциональными зависимостями, и тестовый код должен поддерживать это.

Это привело к ряду проблем:

• https://github.com/codehaus-plexus/plexus-languages/pull/164. Есть работающее решение для этой проблемы (https://github.com/jdbi/jdbi/commit/a2d0e651662fbb7e58d7c51da21b410422d62206).
• https://issues.apache.org/jira/browse/SUREFIRE-2190 (фикс слился, но surefire ещё не был выпущен после слияния).
• https://issues.apache.org/jira/browse/SUREFIRE-2191 является препятствием для тестового модуля.

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

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

Нет хорошего решения для этого, кроме упаковывания тестового кода внутри основных артефактов для выполнения в одном модуле JPMS. Текущий инструмент surefire обходит эту проблему путём исправления тестовых классов в основной артефакт с помощью --patch-module.

Граф зависимостей тестирования ошибочен и хрупок при более сложных сетях зависимостей.

ЗаключениеПереход Jdbi к полной поддержке JPMS будет сложным, если значительные изменения в структуре базы кода считаются недопустимыми. Есть некоторые предложения (например, https://github.com/jdbi/jdbi/pull/2453, который сосредоточен на компиляции), но пока нет хорошего пути вперед.

Фокус следует направить на установку инструментов, которые позволят нам выпускать javadoc, совместимую с Java 11. Устранение различных проблем с построением и тестированием базы кода займет больше времени.

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