Мысли об открытом письме JPMS

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

Я не особо связан с системами Jigsaw или Java-модулей, поэтому у меня нет собаки в этой битве, но, поскольку я с самого начала читал списки рассылки Jigsaw, мое имя случайно появилось в письме (из-за того, что я написал электронное письмо с предложениями), я полагаю, что могу предложить альтернативную, возможно, более нейтральную точку зрения.

Фон

Документ очень длинный. В нем много замечаний, с некоторыми из которых я согласен. Но я думаю, что стоит читать со скептическим взглядом. Несмотря на то, что авторы перечисляют вверху, случайному читателю можно простить то, что он не знает, что многие из них работают над тем, что эффективно конкурирует с Jigsaw, такими как JBoss Modules и OSGi.

Я не собираюсь участвовать в аргументации ad-hominem, поскольку эти моменты носят технический характер, и я перейду к ним через мгновение, но стоит подумать, возможно ли для команды Java интегрировать в JDK конкурента, чтобы существующие проекты без вызывания подобных претензий… претензий, которые часто сводятся к тому, что «мы были здесь первыми, поэтому то, что мы сделали, является наилучшей практикой, и вы тоже должны это делать».

Приведу пример. В самом первом абзаце письма говорится, что Jigsaw - это «новое изобретение чистых помещений» системы, которая «полностью не опробована ни в одном реальном приложении». Далее говорится, что «многие варианты использования», которые сегодня «широко внедряются», невозможны в Jigsaw. Эта формулировка может относиться буквально к любому новому продукту, выходящему на рынок с более сложными игроками.

К сожалению, это одна из нескольких частей документа, которая меня обеспокоила. У Jigsaw был многолетний период разработки и обратной связи, в течение которого мнения других создателей модульных систем снова и снова приводили к существенным изменениям в конструкции. Отзывы были получены от всех, кто появился, даже от таких людей, как я, Java. Поэтому, учитывая, как часто отзывы Red Hat влияли на дизайн Jigsaw, кажется мелочным и неправильным называть его «чистым помещением», подразумевая, что он разрабатывался изолированно от внешнего мира.

Рынок модульных систем

Важно понимать рыночный контекст, в котором возникает этот спор.

В Java нет модульных систем, которые я бы назвал успешными. Самым известным, вероятно, является OSGi, в котором используется широкое определение слова «хорошо известный». OSGi чрезвычайно сложен, и всякий раз, когда я смотрел на него, мне было очень трудно начать. Это не только мое мнение. На прошлой неделе я упомянул OSGi своей команде. Один из моих самых опытных инженеров сказал, что он тоже некоторое время назад смотрел на него и был удивлен тем, насколько сложным он казался.

Отчасти это связано с тем, что это спецификация с множеством реализаций, поэтому, например, переход на веб-сайт OSGi предоставит вам не учебное пособие по началу работы, а, скорее, рекламу конференций и маркетинговые материалы для управляющего консорциума. Переход по ссылкам с заманчивыми названиями, такими как С чего начать, просто дает вам кучу ссылок на внешние учебные материалы, написанные поставщиками реализации, ни одно из которых не является хорошим. Также есть список из пяти различных книг по этой теме. Этот опыт разработчика не очень хорош. Но в основном это сложно, потому что его конструкция действительно огромна.

Учитывая, что большая часть критики в этом документе может быть сформулирована как Jigsaw - это не то же самое, что наши собственные модульные системы, и учитывая отсутствие широкого рыночного успеха существующих модульных систем (извините, ребята!) , Я думаю, мы должны немного расслабить команду Oracle. Они пытаются создать модульную систему для масс, что может повлечь за собой отказ от поддержки всех возможных вариантов использования, которые были заложены в модули OSGi или JBoss на протяжении многих лет. И на самом деле, как можно увидеть на странице обсуждения спецификации, многие функции, описываемые как критические недостатки, были исключены просто на том основании, что они добавляют слишком много сложности и риска. Учитывая плохой инструментарий, плохую документацию и вертикальную кривую обучения, которая типична для этого пространства, трудно категорически осудить ограничение объема новой модульной системы.

В документе слишком много моментов, которые я затронул в документе, поэтому я выделю их и разделю на сильные и слабые (очевидно, по моему собственному скромному мнению).

Слабая критика

Формат дескриптора

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

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

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

JBoss использует XML для определения модулей. XML вышел из моды в последние годы по уважительным причинам: это формат, который не подходит ни людям, ни машинам. OSGi использует формат типа «Ключ: a = b, c = d» МАНИФЕСТА. Я не обнаружил, что ни то, ни другое не особо читаемо. Jigsaw использует исходный код с грамматикой, разработанной специально для определения модулей, подход, который, как я считаю, имеет лучшее удобство использования, чем общий синтаксис, такой как XML или файлы манифеста, и он переводится во время сборки в двоичный, что гораздо лучше подходит для высокопроизводительных виртуальных машины написанные на C ++. Учитывая, что пользователю в любом случае необходимо компилировать исходный код в файлы классов, это вряд ли является серьезным требованием.

Двоичный код или текст - это что-то вроде пробелов и табуляций - мы не собираемся решать вопрос, что лучше здесь. Но формулируя нюансный выбор дизайна, как если бы это был неоспоримый факт, документ подрывает его собственный авторитет (и без нужды, поскольку с Jigsaw есть гораздо более важные проблемы, чем это).

Управление версиями

В документе говорится:

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

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

Мы можем сравнить Jigsaw с OSGi и JBoss. Подход OSGi к управлению версиями поистине сумасшедший - он использует не только версии модулей, но и подпакеты внутри модулей, и он налагает значительно более строгий шаблон строки версии, чем Jigsaw. Я хотел написать о том, что требуется модулям JBoss, но, к сожалению, в документации, кажется, не сказано, это просто относится к слотам, которые, очевидно, могут быть любой произвольной строкой. На самом деле документы JBoss Modules настолько редки, что почти бесполезны: например, страница Исполняемые модули пуста, а вводная страница не обновлялась с 2011 года.

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

Экстренный выключатель

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

Это слабо. Есть несколько переключателей. —-permit-illegal-access option предназначен для того, чтобы помочь разработчикам выяснить, где их код пересекает границы модуля способами, которые не объявляются, поэтому он печатает, когда это происходит, потому что это опция диагностики. Но, используя флаги —-add-opens и —-add-exports, вы можете таким же образом переопределить модульную систему, не выводя никаких предупреждений, чтобы кодировать исключения и исправления модулей в вашей программе в долгосрочной перспективе. Вряд ли это кажется большим делом.

Визуальное сравнение

Такая таблица с флажками, в которой перечислены только те функции, которые есть у вашего продукта, независимо от их важности, является классической маркетинговой техникой. Это также схематично в более глубоком смысле. В их таблице написано «Теоретически возможно AOT-компиляция» и отмечены все модульные системы. Но приложения на основе Jigsaw на самом деле можно компилировать AOT не только теоретически, но и на практике, используя новый инструмент jlink, который является ключевой частью ценностного предложения Jigsaw (это своего рода статический компоновщик для Java).

Выражая это как «теоретически возможно» и отмечая галочку у собственных систем, на самом деле это должно быть «Поддерживает AOT-компиляцию модульных приложений», и только Jigsaw получает галочку…. ну, мне это кажется ударом ниже пояса.

Твит

В коротком разделе, в котором утверждается, что обратной совместимости Jigsaw недостаточно, в качестве доказательства приводится следующая цитата:

"Ok. Нахуй совместимость Пазла. Если для этого потребуется использование инструментов Java 9, у меня будет интересный уровень поддержки в течение следующих 2+ лет », - Тату Салоранта (автор Jackson, WoodStox, ClassMate, TStore)

Эта цитата не говорит об обратной совместимости, поэтому на самом деле не поддерживает высказанную мысль, но все же мне было любопытно насчет контекста, потому что Джексон - важная библиотека. К сожалению, эта цитата - твит без контекста. Я не уверен, почему кто-то мог ожидать, что функция, добавленная в Java 9, не потребует использования инструментов Java 9, но, в любом случае, искренний аргумент Тату слегка подрывается его биографией в Twitter, в которой говорится: «Рэнт сначала, проанализируйте позже! Тогда подумай ». Может быть, это один из тех случаев.

Есть достаточно реальных моментов, чтобы спорить о дизайне Пилы, и аргументы в виде твита не нужны.

Сильные стороны

  • Один загрузчик классов для каждого приложения (по умолчанию). Скрытые конфликты пакетов, вероятно, будут проблемой. Конечно, сейчас они не работают должным образом, потому что упорядочение путей к классам часто нестабильно и на них нельзя полагаться, но идеальная модульная система на самом деле решает подобные проблемы, а не просто отмечает их как ошибки при запуске. . Часто кажется, что Jigsaw по умолчанию просто отображает ранее нестабильные конфигурации как ошибки запуска, что кажется незначительным прогрессом по сравнению с устранением проблемы. Другие проблемы в этом разделе, такие как несколько несовместимых версий одного и того же модуля, связаны между собой. Честно говоря, поддержка нескольких версий в одном процессе не исключена полностью: команда Jigsaw заявила, что это может быть реализовано в будущем выпуске. И реализация действительно может сделать это с дополнительной внешней помощью, что укрепляет доверие к этой позиции.
  • Обработка ресурсов. Похоже, немного беспорядка.
  • Именование модулей. Эстетическая согласованность того, что идентификаторы модулей выглядят так же, как идентификаторы пакетов Java, очевидна, но уже существует целый ряд имен модулей, которые выглядят как координаты Maven. Jigsaw выбирает стиль Java, а затем предлагает различные эвристики, чтобы попытаться сопоставить то, что на самом деле используется, с тем, что использует Jigsaw, что только добавляет сложности: отсутствие которого является основной частью оправдания использования Jigsaw в первую очередь (вместо того, чтобы просто внедрять OSGi оптом).
  • Судьба javax.annotations. Я предполагаю, что любая попытка модульности JDK будет иметь такого рода проблемы. Это не повод использовать другие системы, которые даже не пробуют.

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

Заключение

Последние мысли. Jigsaw не использует подмножество функций OSGI / JBoss и не считает это обычным делом. Он также предлагает важные новые функции. В документе о них просто не упоминается, а жаль. Например:

  • Модульное построение вашего приложения с помощью Jigsaw позволяет вам использовать JLink, инструмент, который может создавать минимизированную и сильно оптимизированную комбинацию «статически связанной» JVM / приложение, избавляя ваших пользователей от необходимости предоставлять свои собственные JVM.
  • JLink может использовать статически заданный строгий характер модулей Jigsaw, чтобы выяснить, какие модули нужны вашему приложению, а затем выполнить предварительную компиляцию всего этого в собственный код. Никакая другая модульная система не может этого сделать.
  • Jigsaw модулирует сам JDK. Это значительная часть работы, которую другие модульные системы не выполняли (хотя теоретически они могли бы это сделать, поскольку JDK является открытым исходным кодом).
  • Инструменты были расширены, например, javadoc теперь знает, как рисовать диаграммы модулей и как создавать документы API, которые показывают границы модулей. Инструменты часто являются слабым местом других модульных систем.
  • Хотя технически Jigsaw является реализацией спецификации (JPMS), платформе Java всегда удавалось избежать кошмара UX, который случился с OSGi: Jigsaw так же хорошо документирован, как и следовало ожидать от JDK, есть множество руководств для вас. можно использовать для его изучения, и он обеспечивает такой же баланс функций и сложности, как и остальная часть платформы Java.

Без сомнения, модульное построение экосистемы Java займет годы и потребует разбивания более чем нескольких яиц на этом пути. Я не уверен, что этот процесс был бы проще, если бы Jigsaw был просто клоном модулей OSGi или JBoss. Чтобы заставить разработчиков разбивать свои приложения на модули, недостаточно просто создать модульную систему. Вам нужно сделать его достаточно простым, чтобы занятые разработчики могли его усвоить, и вам нужно предоставить несколько крупных функций, чтобы мотивировать работу.

Прочитав весь документ и записав этот гигантский ответ, я на самом деле обнаружил, что испытываю симпатию к Пиле, а не теряю ее. Команда предпочла конкурировать с существующими решениями, а не просто их внедрять, потому что существующие решения были отвергнуты рынком. Это означает оспаривание некоторых проектных решений, принятых другими специалистами по модульным системам, и неизбежно приведет к трению. Это не значит, что Jigsaw - неудачник. Когда я говорю пользователям, что им следует избегать его использования ни при каких обстоятельствах, как это делается в этом документе, я воспринимаю его как тонкую, несколько закулисную форму конкурентного маркетинга. «Все должны использовать OSGi или JBoss» - это просто нереалистичная альтернатива, и действительно, авторы не вполне ходят туда. Вместо этого создается впечатление, что они предпочли бы, чтобы экосистема Java вообще не делалась на модули.

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