/ фото Matthias Ripp CC
Java Development Kit 9 продвигался к своему запланированному релизу 27 июля. Однако Red Hat и IBM выразили недовольство концепцией модуляризации (подпроект Jigsaw). Предполагается, что модульное построение дает небольшим устройствам определенные плюсы, в том числе масштабируемость. Но Скотт Старк (Scott Stark), вице-президент группы JBoss из Red Hat, высказал несколько опасений касательно работы приложений с системой модулей и её влияния на грядущую Java Enterprise Edition 9.
Старк отметил, что система модулей, которая описана в JSR-376 и проекте Jigsaw, может привести к появлению «двух миров Java»: одного для Jigsaw и одного для всего остального, включая загрузчики классов Java SE и OSGI. В своем анализе Старк учитывал мнение других участников сообщества Java.
«Многие решения, которые широко применяются сегодня, окажутся нежизнеспособны при использовании Jigsaw или потребуют серьезных изменений в архитектуре», — сказал Старк.
Компания IBM тоже присоединилась к этому обсуждению и выразила сомнения относительно плана развития модулей. Тим Эллисон (Tim Ellison), ведущий технический специалист IBM, разделяет опасения Старка и отмечает, что «необходимо провести дополнительную работу, дабы достичь полного соглашения касательно предлагаемого стандарта».
В ответ на это в компании Oracle также выступили с критикой, но направили её на заявления IBM и Red Hat. Марк Рейнхолд (Mark Reinhold), главный архитектор Java в Oracle, назвал позицию IBM «разочаровывающей», «необычной», а также угрозой для Java. Что касается позиции Red Hat, то Рейнхолд назвал её «разочаровывающей, но не удивительной», а также попыткой защитить собственную модульную систему, припомнив компании сервер приложений WildFly. В блоге он отметил, что голосование против JSR-376 — это голосование против JCP.
Само же голосование прошло 8 мая, а его результаты опубликовали на странице Java Community Process. В поддержку JSR-376 были отданы десять голосов, тринадцать — против. Поскольку необходимое число голосов (2/3) набрать не удалось, период рассмотрения проекта продлили еще на 30 дней. После внесения изменений, голосование будет проведено повторно. При этом многие из участников отметили тот факт, что проблемы спецификации JSR-376 можно исправить в ближайшее время, и это не должно сильно отразиться на расписании выхода Java 9.
Отметим, что ранее выход Java 9 неоднократно откладывался. Причиной тому была все та же модуляризация. Дата релиза переносилась сначала на март 2017 года, а затем на июль. Основание — нужно было больше времени на разработку системы модулей. По словам Марка Рейнхолда (Mark Reinhold), главного архитектора Java в Oracle, это было связано с большим количеством ошибок, ожидающих устранения.
О компании Oracle
Корпорация Oracle является крупнейшим в мире поставщиком корпоративного программного обеспечения. Компания основана в 1977 году. Подразделения корпорации расположены более чем в 145 странах, в которых работают более 120 тыс. сотрудников. По состоянию на 2014 год компания владеет 30% глобального рынка программного обеспечения.
О компании IBM
IBM — один из крупнейших в мире производителей и поставщиков аппаратного и программного обеспечения, а также ИТ-сервисов и консалтинговых услуг. Компания была основана 16 июня 1911 года.
О компании Red Hat
Red Hat — американская компания, выпускающая решения на основе свободной операционной системы Linux. Компания начала свою работу в 1993 году, и на данный момент насчитывает более 3500 сотрудников и 30 подразделений по всему миру, являясь одной из крупнейших компаний, выпускающих Linux.
P.S. Еще несколько материалов из нашего блога:
- Дизайн зон доступности в vCloud Director
- Unboxing all-flash СХД NetApp AFF A300: технические характеристики и взгляд изнутри
- vCloud Director: как создать безопасное подключение между двумя организациями
- IaaS в мире музыки: как облако становится стандартом размещения аудиоконтента
- Особенности выбора между частным, публичным и гибридным облаком
Построение аттестуемых и защищенных инфраструктур на базе решений VMware
Комментарии (30)
Regis
10.05.2017 17:30+1Почему IBM и RedHat стали предъявлять претензии только сейчас? Ведь спеке не один год. Почему они раньше не высказались?
Throwable
10.05.2017 17:44+3Очевидно, это разные люди — те, кто пишет спецификации и те, кто разрабатывает софт. Когда появился более-менее стабильный кандидат девятки, компании попробовали портировать свой стек под новую платформу и во многом обломались. Я не уверен, что изначально даже был сделан анализ более-менее распространенных библиотек, фрекмворков и тулзов на предмет насколько их затронет изменение и какие могут быть методы решения. В любом случае, выход девятки — это будет глобальный сплит всей экосистемы.
Regis
10.05.2017 19:07Очевидно, это разные люди — те, кто пишет спецификации и те, кто разрабатывает софт.
Вы хотите сказать в том же IBM отдельно сидят люди, которые участвуют в JCP и отдельно те, кто пишет софт и причем первые не общаются со вторыми? Не проблема ли это IBM?
Я не уверен, что изначально даже был сделан анализ более-менее распространенных библиотек, фрекмворков и тулзов на предмет насколько их затронет изменение и какие могут быть методы решения. В любом случае, выход девятки — это будет глобальный сплит всей экосистемы.
Такие анализы делались. Другое дело, что, очевидно, у разработчиков Java нет возможности изучить и протестировать всё. Поэтому еще год назад от них были призывы "если вы видите какие-то проблемы у вашей библиотеки/фреймворка при переходе на Jigsaw — напишите нам!".
Throwable
10.05.2017 22:57+1Вы хотите сказать в том же IBM отдельно сидят люди, которые участвуют в JCP и отдельно те, кто пишет софт и причем первые не общаются со вторыми? Не проблема ли это IBM
Это проблема не только IBM, а всех крупных компаний, где есть жесткое разделение труда. И да, специалисты, участвующие в JCP, возможно не писали реальный бизнес-код уже лет десять или больше.
Поэтому еще год назад от них были призывы "если вы видите какие-то проблемы у вашей библиотеки/фреймворка при переходе на Jigsaw — напишите нам!".
Это когда еще мало-мальски стабильной девятки не было? Есть очень много решений, базирующихся на classpath. SLF4J использует classpath для поиска бэкенда для логгинга и настроек. Чтобы это сработало в модульной среде, библиотека должна быть изменена концептуально. И все остальные библиотеки, использующие SLF4J, будут ждать, пока мейнтейнеры соизволят выпустить его модульную версию, а также модульную версию всех своих зависимостей. И так с каждыми библиотеками, фреймворками и тулзами для сборки, тестинга и, наконец, продуктами. Период перехода может затянуться лет на 5 или больше, и все это время придется поддерживать две версии. В итоге экосистема сплитанется на две — модульную и classpath-ную.
А теперь главный вопрос: в чем реальный профит модульности?
semio
11.05.2017 09:14+1В slf4j уже внесены соответствующие изменения: https://www.slf4j.org/faq.html#changesInVersion18
APXEOLOG
11.05.2017 09:29+2Никто не заставляет весь энтерпрайз сломя голову переходить на 9ю версию в день релиза. Многие приложения до сих пор на java 6 работают, и ничего. Другое дело, что для того, чтобы процесс перехода начался — релиз должен состояться.
lany
10.05.2017 17:48+1Потому что они высказались. По крайней мере RedHat высказывал конкретные претензии множество раз. Почитайте мейлинг-лист jpms-spec-observers. В первую очередь сообщения от Дэвида Ллойда и ответы от Марка. Там уже не первый год отнюдь не дружелюбное общение.
Regis
10.05.2017 18:43Если так, то непонятно, почему проблемы не были адресованы раньше. Попытка продавить, что есть?
lany
10.05.2017 20:06+4Почему же не были? В чём-то согласились с RedHat, в чём-то нашли компромисс. Какие-то вещи технически сложны и при этом могут быть реализованы в будущих версиях, поэтому их отложили. Какие-то вещи концептуально не подходят для JPMS.
Например, RedHat топит за циклические зависимости. Конечно, с точки зрения поддержки легаси-кода это может быть важно, но с точки зрения нормальной архитектуры — бред. Не можешь избавиться от циклов — не переходи на JPMS. Тут, я считаю, Марк правильно не прогибается. Вот pjBooms рассказывал в красках на JBreak, что не так с циклическими зависимостями в OSGi. Вроде бы они есть, но это хрупкий песчаный замок: порядок инициализации циклически-зависимых OSGi-модулей оказался зависим от неспецифицированных деталей реализации процесса загрузки классов в HotSpot. Приложения, которые хотят циклические зависимости, как правило, ещё и на этот порядок закладываются. Немного меняешь процесс загрузки классов в JVM (не нарушая спецификацию), и большие OSGi-приложения вроде Eclipse (привет IBM) дохнут, не успев запуститься. А другие большие приложения, но не OSGi (типа IntelliJ IDEA) продолжают работать. И если я правильно понял, в рамках спецификации OSGi проблема в принципе неразрешима. Если тащить циклические зависимости в JPMS, придётся тащить и эту проблему. Даже если предположить, что в JPMS протащат циклические зависимости, никто не будет реализовывать Jigsaw, чтобы он эмулировал в точности поведение OSGi. А значит, существующие OSGi-приложения всё равно развалятся и их всё равно придётся переделывать. А раз переделывать, то лучше и циклы выкорчевать, тогда порядок инициализации станет стабильным.
Regis
10.05.2017 21:27Тогда становится не очень понятна позиция RedHat — ведь даже если с ней согласятся (добавят циклы), то проблему RedHat'а это не решит. В чем тогда смысл?
pjBooms
11.05.2017 07:04+1Они кроме циклов хотят полный набор фич, который бы им позволил сделать свои модули поверх стандартных. Кроме циклов — это версии, небинарное представление модулей (желательно плаггэбл), ленивый резолв. И со всеми этим делами есть проблемы в OSGi, которые никто тянуть в JPMS не будет.
pjBooms
11.05.2017 07:00+1Основной камень преткновения даже не циклические зависимости, а версии. IBM настаивает, чтобы проблема версий адресовалась Jigsaw. На что Марк правильно парирует, что так как они адресуются в OSGi — делать нельзя. Для проблемы версий в Jigsaw ввели слои (layers), но их ease-of-use пока еще оставляет желать лучшего. Эту проблему Марк и говорит, что можно адресовать в будущем.
Но в любом случае JPMS не будет концептуально совместим c OSGi (и JBoss modules) и это собственно сильно расстраивает IBM и Red Hat. Они не смогут сделать новую версию OSGi на базе JPMS модулей, а значит OSGi придется жить вне стандартного модулярного мира.
lany
10.05.2017 17:46+6Из какой конкретно строки в оригинальной статье вы сделали вывод, что «Выход Java 9 — новой версии платформы — был отложен»? Что-то я не вижу этого в явном виде. Более того, статья написана неделю назад, задолго до конца голосования, когда исход был ещё неясен. Официально об откладывании Java 9 никто пока не объявил. Захотелось заголовок погромче сделать? :-)
tankomazzz
10.05.2017 18:01страшно мне что-то стало из-за голосования 10\13
APXEOLOG
11.05.2017 09:36Многие проголосовали против только для того, чтобы дать лишний месяц на доработку проекта и у них нет концептуальных претензий
kontiky
11.05.2017 22:37Выход Java 9 никто не отложил. Количество дней до выхода
http://www.java9countdown.xyz/
ACPrikh
12.05.2017 13:27-41. Выход — новый язык.
2. Бренд и количествоговнокодасофта на Яве перетягивают. Отсутствие модульности — это изначальный фэйл. Тормознутая виртуальная машина хороша, пока каналы связи медленные.
Это начало агонии. Если Google выпустит новую ОС…
Но, см. 2.Regis
12.05.2017 17:12+2Эээ… И много вы можете назвать языков с аналогом модулей, которые будут в Jigsaw?
ACPrikh
18.05.2017 09:15-2Ну вот. Подтверждение моим словам. Такой авторитетный игрок в области программирования, как Google официально объявил о поддержке языка Kotlin.
Кстати, российская разработка. Со своим IDE.
Минусёрам позор. Google таким образом доказал, что дураки обычно агрессивны.
DarkOrion
13.05.2017 23:15+2Кто бы мне объяснил зачем модули как-то отдельно от пакетов. Почему бы не превратить пакеты в модули и не вводить лишний уровень иерархии.
Regis
19.05.2017 19:19+1Допустим я раскидал десяток классов по по 4-5 пакетам просто ради более логичной организации стуктуры. Предлагаете всё это конвертировать в 5 модулей и делать изоляцию на уровне JVM? Оверхэд же будет дикий.
yetanothercoder
19.05.2017 19:31ага, +тонны мелких пакетов в миллионе опенсорс либ или даже самой jdk
rbobot
dotnet core отрывается еще дальше
alek_sys
Там тоже свои страсти кипят — ASP.NET Core 2.0 внезапно оказалась несовместима с .NET Framework 4 (который полный), а только с .NET Core 2.0. Уже почти 600 комментариев к issue.
ggrnd0
Так говорили о совместимости с 4.6.1, а net40 похоронили еще в 2013-2014 в самом начале.
P.S. это превью версия, которая пока поддерживает только .net core 2.0