Pull to refresh

Comments 32

Там тоже свои страсти кипят — ASP.NET Core 2.0 внезапно оказалась несовместима с .NET Framework 4 (который полный), а только с .NET Core 2.0. Уже почти 600 комментариев к issue.
UFO just landed and posted this here

Почему IBM и RedHat стали предъявлять претензии только сейчас? Ведь спеке не один год. Почему они раньше не высказались?

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

Очевидно, это разные люди — те, кто пишет спецификации и те, кто разрабатывает софт.

Вы хотите сказать в том же IBM отдельно сидят люди, которые участвуют в JCP и отдельно те, кто пишет софт и причем первые не общаются со вторыми? Не проблема ли это IBM?


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

Такие анализы делались. Другое дело, что, очевидно, у разработчиков Java нет возможности изучить и протестировать всё. Поэтому еще год назад от них были призывы "если вы видите какие-то проблемы у вашей библиотеки/фреймворка при переходе на Jigsaw — напишите нам!".

Вы хотите сказать в том же IBM отдельно сидят люди, которые участвуют в JCP и отдельно те, кто пишет софт и причем первые не общаются со вторыми? Не проблема ли это IBM

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


Поэтому еще год назад от них были призывы "если вы видите какие-то проблемы у вашей библиотеки/фреймворка при переходе на Jigsaw — напишите нам!".

Это когда еще мало-мальски стабильной девятки не было? Есть очень много решений, базирующихся на classpath. SLF4J использует classpath для поиска бэкенда для логгинга и настроек. Чтобы это сработало в модульной среде, библиотека должна быть изменена концептуально. И все остальные библиотеки, использующие SLF4J, будут ждать, пока мейнтейнеры соизволят выпустить его модульную версию, а также модульную версию всех своих зависимостей. И так с каждыми библиотеками, фреймворками и тулзами для сборки, тестинга и, наконец, продуктами. Период перехода может затянуться лет на 5 или больше, и все это время придется поддерживать две версии. В итоге экосистема сплитанется на две — модульную и classpath-ную.


А теперь главный вопрос: в чем реальный профит модульности?

В slf4j уже внесены соответствующие изменения: https://www.slf4j.org/faq.html#changesInVersion18

Никто не заставляет весь энтерпрайз сломя голову переходить на 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'а это не решит. В чем тогда смысл?

Они кроме циклов хотят полный набор фич, который бы им позволил сделать свои модули поверх стандартных. Кроме циклов — это версии, небинарное представление модулей (желательно плаггэбл), ленивый резолв. И со всеми этим делами есть проблемы в OSGi, которые никто тянуть в JPMS не будет.

Но ведь эти фичи вроде как были изначально заявлены как "out of scope" для Jigsaw в 9-ке. Я ошибаюсь?

UFO just landed and posted this here
Да, именно так. Но Баба Яга (IBM и RedHat) по прежнему против :)
Основной камень преткновения даже не циклические зависимости, а версии. IBM настаивает, чтобы проблема версий адресовалась Jigsaw. На что Марк правильно парирует, что так как они адресуются в OSGi — делать нельзя. Для проблемы версий в Jigsaw ввели слои (layers), но их ease-of-use пока еще оставляет желать лучшего. Эту проблему Марк и говорит, что можно адресовать в будущем.

Но в любом случае JPMS не будет концептуально совместим c OSGi (и JBoss modules) и это собственно сильно расстраивает IBM и Red Hat. Они не смогут сделать новую версию OSGi на базе JPMS модулей, а значит OSGi придется жить вне стандартного модулярного мира.

Из какой конкретно строки в оригинальной статье вы сделали вывод, что «Выход Java 9 — новой версии платформы — был отложен»? Что-то я не вижу этого в явном виде. Более того, статья написана неделю назад, задолго до конца голосования, когда исход был ещё неясен. Официально об откладывании Java 9 никто пока не объявил. Захотелось заголовок погромче сделать? :-)

страшно мне что-то стало из-за голосования 10\13

Многие проголосовали против только для того, чтобы дать лишний месяц на доработку проекта и у них нет концептуальных претензий

UFO just landed and posted this here
1. Выход — новый язык.
2. Бренд и количество говнокода софта на Яве перетягивают. Отсутствие модульности — это изначальный фэйл. Тормознутая виртуальная машина хороша, пока каналы связи медленные.
Это начало агонии. Если Google выпустит новую ОС…
Но, см. 2.

Эээ… И много вы можете назвать языков с аналогом модулей, которые будут в Jigsaw?

Ну вот. Подтверждение моим словам. Такой авторитетный игрок в области программирования, как Google официально объявил о поддержке языка Kotlin.

Кстати, российская разработка. Со своим IDE.
Минусёрам позор. Google таким образом доказал, что дураки обычно агрессивны.

Ничего, что Kotlin поверх JVM работает?

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

[Котлин] позиционируется разработчиками как объектно-ориентированный язык промышленного[уточнить] уровня, а также как язык, который сможет заменить Java

Естественно, ведь мягкая или динамическая типизация — источник говнокода.
JVM — переемственность с Ява см. 1 пункт. Надо майновать раскрученный бренд.
Кто бы мне объяснил зачем модули как-то отдельно от пакетов. Почему бы не превратить пакеты в модули и не вводить лишний уровень иерархии.

Допустим я раскидал десяток классов по по 4-5 пакетам просто ради более логичной организации стуктуры. Предлагаете всё это конвертировать в 5 модулей и делать изоляцию на уровне JVM? Оверхэд же будет дикий.

ага, +тонны мелких пакетов в миллионе опенсорс либ или даже самой jdk
Sign up to leave a comment.