Comments 32
Почему IBM и RedHat стали предъявлять претензии только сейчас? Ведь спеке не один год. Почему они раньше не высказались?
Очевидно, это разные люди — те, кто пишет спецификации и те, кто разрабатывает софт. Когда появился более-менее стабильный кандидат девятки, компании попробовали портировать свой стек под новую платформу и во многом обломались. Я не уверен, что изначально даже был сделан анализ более-менее распространенных библиотек, фрекмворков и тулзов на предмет насколько их затронет изменение и какие могут быть методы решения. В любом случае, выход девятки — это будет глобальный сплит всей экосистемы.
Очевидно, это разные люди — те, кто пишет спецификации и те, кто разрабатывает софт.
Вы хотите сказать в том же IBM отдельно сидят люди, которые участвуют в JCP и отдельно те, кто пишет софт и причем первые не общаются со вторыми? Не проблема ли это IBM?
Я не уверен, что изначально даже был сделан анализ более-менее распространенных библиотек, фрекмворков и тулзов на предмет насколько их затронет изменение и какие могут быть методы решения. В любом случае, выход девятки — это будет глобальный сплит всей экосистемы.
Такие анализы делались. Другое дело, что, очевидно, у разработчиков Java нет возможности изучить и протестировать всё. Поэтому еще год назад от них были призывы "если вы видите какие-то проблемы у вашей библиотеки/фреймворка при переходе на Jigsaw — напишите нам!".
Вы хотите сказать в том же IBM отдельно сидят люди, которые участвуют в JCP и отдельно те, кто пишет софт и причем первые не общаются со вторыми? Не проблема ли это IBM
Это проблема не только IBM, а всех крупных компаний, где есть жесткое разделение труда. И да, специалисты, участвующие в JCP, возможно не писали реальный бизнес-код уже лет десять или больше.
Поэтому еще год назад от них были призывы "если вы видите какие-то проблемы у вашей библиотеки/фреймворка при переходе на Jigsaw — напишите нам!".
Это когда еще мало-мальски стабильной девятки не было? Есть очень много решений, базирующихся на classpath. SLF4J использует classpath для поиска бэкенда для логгинга и настроек. Чтобы это сработало в модульной среде, библиотека должна быть изменена концептуально. И все остальные библиотеки, использующие SLF4J, будут ждать, пока мейнтейнеры соизволят выпустить его модульную версию, а также модульную версию всех своих зависимостей. И так с каждыми библиотеками, фреймворками и тулзами для сборки, тестинга и, наконец, продуктами. Период перехода может затянуться лет на 5 или больше, и все это время придется поддерживать две версии. В итоге экосистема сплитанется на две — модульную и classpath-ную.
А теперь главный вопрос: в чем реальный профит модульности?
Никто не заставляет весь энтерпрайз сломя голову переходить на 9ю версию в день релиза. Многие приложения до сих пор на java 6 работают, и ничего. Другое дело, что для того, чтобы процесс перехода начался — релиз должен состояться.
Потому что они высказались. По крайней мере RedHat высказывал конкретные претензии множество раз. Почитайте мейлинг-лист jpms-spec-observers. В первую очередь сообщения от Дэвида Ллойда и ответы от Марка. Там уже не первый год отнюдь не дружелюбное общение.
Если так, то непонятно, почему проблемы не были адресованы раньше. Попытка продавить, что есть?
Почему же не были? В чём-то согласились с RedHat, в чём-то нашли компромисс. Какие-то вещи технически сложны и при этом могут быть реализованы в будущих версиях, поэтому их отложили. Какие-то вещи концептуально не подходят для JPMS.
Например, RedHat топит за циклические зависимости. Конечно, с точки зрения поддержки легаси-кода это может быть важно, но с точки зрения нормальной архитектуры — бред. Не можешь избавиться от циклов — не переходи на JPMS. Тут, я считаю, Марк правильно не прогибается. Вот pjBooms рассказывал в красках на JBreak, что не так с циклическими зависимостями в OSGi. Вроде бы они есть, но это хрупкий песчаный замок: порядок инициализации циклически-зависимых OSGi-модулей оказался зависим от неспецифицированных деталей реализации процесса загрузки классов в HotSpot. Приложения, которые хотят циклические зависимости, как правило, ещё и на этот порядок закладываются. Немного меняешь процесс загрузки классов в JVM (не нарушая спецификацию), и большие OSGi-приложения вроде Eclipse (привет IBM) дохнут, не успев запуститься. А другие большие приложения, но не OSGi (типа IntelliJ IDEA) продолжают работать. И если я правильно понял, в рамках спецификации OSGi проблема в принципе неразрешима. Если тащить циклические зависимости в JPMS, придётся тащить и эту проблему. Даже если предположить, что в JPMS протащат циклические зависимости, никто не будет реализовывать Jigsaw, чтобы он эмулировал в точности поведение OSGi. А значит, существующие OSGi-приложения всё равно развалятся и их всё равно придётся переделывать. А раз переделывать, то лучше и циклы выкорчевать, тогда порядок инициализации станет стабильным.
Тогда становится не очень понятна позиция RedHat — ведь даже если с ней согласятся (добавят циклы), то проблему RedHat'а это не решит. В чем тогда смысл?
Но в любом случае JPMS не будет концептуально совместим c OSGi (и JBoss modules) и это собственно сильно расстраивает IBM и Red Hat. Они не смогут сделать новую версию OSGi на базе JPMS модулей, а значит OSGi придется жить вне стандартного модулярного мира.
Из какой конкретно строки в оригинальной статье вы сделали вывод, что «Выход Java 9 — новой версии платформы — был отложен»? Что-то я не вижу этого в явном виде. Более того, статья написана неделю назад, задолго до конца голосования, когда исход был ещё неясен. Официально об откладывании Java 9 никто пока не объявил. Захотелось заголовок погромче сделать? :-)
А вот тепеееерь действительно можно говорить, что выход (скорее всего будет) отложен:
http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-May/005864.html
Вот тут подробнее: Дайджест: судьба Jigsaw
2. Бренд и количество
Это начало агонии. Если Google выпустит новую ОС…
Но, см. 2.
Эээ… И много вы можете назвать языков с аналогом модулей, которые будут в Jigsaw?
Кстати, российская разработка. Со своим IDE.
Минусёрам позор. Google таким образом доказал, что дураки обычно агрессивны.
Ничего, что Kotlin поверх JVM работает?
Java, как язык, развивается очень медленно, новые возможности в языке не появляются (функции первого порядка мы ждем уже не первый год), совместимость со старыми версиями языка делает невозможным появление многих полезных вещей и в ближайшем будущем (например, приличной параметризации типов).
[Котлин] позиционируется разработчиками как объектно-ориентированный язык промышленного[уточнить] уровня, а также как язык, который сможет заменить Java
Естественно, ведь мягкая или динамическая типизация — источник говнокода.
JVM — переемственность с Ява см. 1 пункт. Надо майновать раскрученный бренд.
Выход Java 9 снова отложен