Кому нужны Java модули без разрешения версий?

не использую.

ЗЫ. тебя тоже корёжит от «патх»?

Кто из присутствующих использует свои Java модули в продакшене?

Все до сих пор сидят на восьмой яве. Вот сейчас поддержку дропнут, все переползут на 11-ю и потихоньку модули начнут использовать.

Я для себя вижу пользу модулей только при использовании jlink. Тогда можно свой рантайм поставлять и только с нужными модулями. Удобно, не надо весь jre впихивать или надеяться на системный.

Все до сих пор сидят на восьмой яве. Вот сейчас поддержку дропнут, все переползут на 11-ю и потихоньку модули начнут использовать.

Не начнут. Java 11 прекрасно работет и без модулей, а модули никаких особых преимуществ не дают.

Я для себя вижу пользу модулей только при использовании jlink. Тогда можно свой рантайм поставлять и только с нужными модулями. Удобно, не надо весь jre впихивать или надеяться на системный.

Неужели диски сильно подорожали? Размер JRE никогда не был ни для кого проблемой. По крайней мере в мире Enterprise.

Не начнут. Java 11 прекрасно работет и без модулей, а модули никаких особых преимуществ не дают.

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

Неужели диски сильно подорожали? Размер JRE никогда не был ни для кого проблемой. По крайней мере в мире Enterprise.

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

Это породит множество багов. Например есть static-переменная. Если зависимостей будет много, это приведёт к множеству этих переменных для каждой версии библиотеки, т.е. код уже будет работать по-другому. Такое надо было в языке делать с самого начала, а не сейчас. Про безумное раздувание кода вообще молчу. Будут десятки apache-commons и guav всяких, с дублирующимся на 99% кодом.

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

А зачем Спрингу переходить на модули? Судя по всему Спринг на них вообще не перейдёт https://jira.spring.io/browse/SPR-13501

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

Там он точно так же не имеет особого значения. Ну будет твой дистрибутив на 100 мегабайт меньше, подумаешь... К тому же, тебя никто не заставляет писать своё приложение как модуль. Создаёшь jlink-ом свою урезаную среду исполнения, прикладываешь к ней обычные безмодульные JAR-ники приложения и библиотек и всё должно работать через Classpath как и раньше.

Это породит множество багов. Например есть static-переменная. Если зависимостей будет много, это приведёт к множеству этих переменных для каждой версии библиотеки, т.е. код уже будет работать по-другому.

Не будет. Каждый модуль будет видеть ровно одну версию каждой из своих зависимостей.

Такое надо было в языке делать с самого начала, а не сейчас.

Там это почти сделали, причём с самого начала - уникальность класса определяется не только его полным названием, но и загрузчиком классов, которым он был загружен. Именно это используется в OSGi, которую Java модули (проект Jigsaw) и должны заменить (смотри доклад Никиты Липского выше). Однако в итоге заменить не получится.

Про безумное раздувание кода вообще молчу. Будут десятки apache-commons и guav всяких, с дублирующимся на 99% кодом.

Тоже не будет, если так же как в OSGi задавать версию не жёстко, а диапазоном или как wildcard. Кстати, в Apache Commons давно существует модульность мажорных версий на уровне названий пакетов.

Судя по всему Спринг на них вообще не перейдёт https://jira.spring.io/browse/SPR-13501

Перейдет, но потом

which might stay that way for several years still until we ship a JDK 11 baselined Spring Framework 6.0 against a new generation of dependencies

Это «потом» может затянуться лет на десять, за которые интерес к модулям может угаснуть или их таки доделают до человеческого состояния:

Specifically, we can't ship module-info files quite yet since we'd need stable module names for all of our optional dependencies... and many of those don't declare stable module names at this point (that is, they don't even include an Automatic-Module-Name manifest entry in their jar). Also, we'd need to build the entire framework on JDK 9+ for the compiler to understand the module-info.java format which is not entirely trivial either, even if the framework itself is known to work fine with JDK 9/10/11 at runtime.

Не будет. Каждый модуль будет видеть ровно одну версию каждой из своих зависимостей.

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

Суть в том, что сейчас это не так.

Ещё хуже, сейчас этого нет совсем.

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

Но они есть уже сейчас. Разве Strong Encapsulation не ломает старый код, который на это не расчитан? А ведь именно Strong Encapsulation позволил бы предотвратить просачивание разных версий классов из разных версий одного и того же модуля куда не следует. Зачем он вообще нужен без поддержки версий модулей?

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

Тот же апачкомонс или гуаву можно было бы разбить на такие модули. А может уже так сделали.

Апачевские commons библиотеки и так неплохо поделены на, кто бы мог подумать, библиотеки. Зачем их делить ещё на модули и сколько килобайт ты собираешься сэкономить?

Jigsaw разрабатывали и пилили 10 лет (с 2008 года) вовсе не для замены утилитных библиотек такими же модулями. Jigsaw разрабатывали как архитектурно правильную альтернативу OSGi и изначально там были версии модулей, причём поддерживались даже диапазоны версий как в OSGi. Из-за этих диапазонов Jigsaw приходилось заниматься разрешением версий на старте приложения, то есть нахождением наиболее подходящих версий модулей из доступных в modules path. В результате такого over engineering-а разработчики столкнулись с NP-полной проблемой, которая действительно делала версирование довольно печальной затеей. Но зачем они пошли по пути диапазонов? Сборщик приложения, такой как Maven или Gradle вполне успешно разрешает версии на этапе сборки. Далее эту информацию надо лишь где-то сохранить, чтобы JVM знал, что в данном конкретном приложении модулю из lor-1.3.jar нужен модуль astral-1.5.jar а модулю opennet-1.7.jar нужен модуль astral-1.2.jar и тогда это никакая не NP-полная проблема, а просто заранее посторенный граф зависимостей с конкретными связями, а не диапазонами. Причём в этом случае нет никаких конфликтов с транзитивными зависимостями.

но какой-то серьёзной заинтересованности в их использовании не заметно.

как и во всём, что пропихнул оракл в java.

Ну почему же во всём? Новшества Java 7 и Java 8 постепенно входят в оборот.

это задел сана, который потихоньку сходит на нет, а заместо него модуля, «скриптинг», неудобоваримое время, распухание API и тому подобные порождения маркетологов.

сколько килобайт ты собираешься сэкономить?

Килобайт? Посмотри любой проект макак там сотни мегабайт библиотек. А разделив каждую библиотеку на модули можно на порядок всё подсократить. Мне, например, у апачей только StringUtils нужны ище пару классов, а я тяну по итогу пару мегабайт (или сколько оно там весит)

Ну так и Jigsaw - это задел Sun, ещё с 2008 года. Модульность планировалось добавить в Java 7, но смогли лишь в Java 9.

Каждая библиотека уже является модулем. Например в apache-commons-lang 3.8.1 в манифесте прописано Automatic-Module-Name: org.apache.commons.lang3. Это один из модулей среди прочих Apache Commons библиотек. Никто не будет делить apache-commons-lang на ещё меньшие модули, это тебя кто-то обманул.

Jigsaw

это был демонстратор технологий, коих было не один, и мне вериться, что сан бы не стала бы его тащить.

Модульность

все были против и сан бы не попёрла против всех.

хотя сан, конечно, после 1.5 тоже оттянулась на поприще - тянем всё модное, но им далеко до ораклёвых инженеров маркетологов.

Это был проект Sun, который планировалось довести до состояния продакшена уже в Java 7. Чувака по имени Mark Reinhold знаешь? Он работает в Sun/Orcacle с 1996 года. Почитай что он написал о Jigsaw в декабре 2008:

https://mreinhold.org/blog/jigsaw

As a first step toward this brighter, modularized world, Sun’s primary goal in the upcoming JDK 7 release will be to modularize the JDK.

There will be other goals, to be sure — more on those later — but the modularization work will drive the release, which we hope to deliver early in 2010.

все были против и сан бы не попёрла против всех.

Кто эти все? Огласите весь список, пожалуйста.

Причём в этом случае нет никаких конфликтов с транзитивными зависимостями.

Это ТЫ так считаешь. JVM работает по-другому: какой класс она загрузила первым (неважно, из какого архива), того и тапки.

iZEN, зачем ты пишешь фигню не разобравшись о чём вообще речь? Разговор вовсе не о Classpath.

Разговор о разных версиях кода в jar-архивах.

ClassA из astral-1.2.jar и astral-1.5.jar по убеждению JVM ничем друг от друга не отличаются. И будет использован тот ClassA, архив которого загрузится первым. ClassA из другого архива будет отброшен несмотря на то, что он нужен для работы других классов. В итоге вылезет ошибка времени связывания при попытке обратиться из работающего кода к публичному интерфейсу ClassA не той версии.

Разговор о разных версиях кода в jar-архивах.

Перечитай тему с самого начала. Разговор идёт о Java модулях, добавленных в Java 9 в рамках проекта Jigsaw. Изначально этот проект поддерживал версии модулей, а значит и разные версии одной той же библиотеки (модуля) в транзитивных зависимостях. Затем от этого там отказались, хотя мултиверсионность существует в OSGi, которую Jigsaw и должен был заменить.

Кстати, уникальность классов определяется не только их полным именем, но так же и загрузчиком классов. То есть даже в какой нибудь Java 6 таки можно загрузить две версии ClassA из astral-1.2.jar и astral-1.5.jar если делать это двумя разными, скажем, URLCLassLoder-ами.

Каждая библиотека уже является модулем

Для обратной совместимости

в apache-commons-lang 3.8.1 в манифесте прописано Automatic-Module-Name: org.apache.commons.lang3

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

Кстати, уникальность классов определяется не только их полным именем, но так же и загрузчиком классов.

Это ясно, как божий день.

в какой нибудь Java 6 таки можно загрузить две версии ClassA из astral-1.2.jar и astral-1.5.jar если делать это двумя разными, скажем, URLCLassLoder-ами.

Облом наступает при инстанцировании класса, так как он теряет связь с класслоадером и оказывается в общем пуле, где нужно только уникальное ClassName.

Для обратной совместимости

Для обратной совместимости это не нужно.

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

Ну и покажи мне хотя бы одну такую библиотеку, которую разделили на ещё меньшие модули и не могли этого сделать раньше без модулей. Таких библиотек нет. Модули в Java добавили вовсе не для разделения библиотек. С таким разделением прекрасно справляются и старые средства даже в Java 1.4. Модули для этого не нужны.

Это ясно, как божий день.

Тогда зачем ты пишешь чушь?

Облом наступает при инстанцировании класса, так как он теряет связь с класслоадером.

Ну вот, ты опять написал чушь.

Смотреть до просветления: https://www.youtube.com/watch?v=E3A6Z02TIjg

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

Мне похеру, что ты там думаешь, но Maven и Gradle нужно брать той версии, которые умеют работать с Jigsaw Layers. Иначе версионирование модулей никак не одолеет Jar Hell.

Какое отношение Jigsaw Layers имеют к Maven и Gradle, а так же к версионированию модулей, которого нет? Тебе ещё не надоело писать чушь?

Ну и покажи мне хотя бы одну такую библиотеку

https://github.com/wizzardo/tools/tree/master/modules/

Модули в Java добавили вовсе не для разделения библиотек.

А разделение библиотеки JDK это что?

С таким разделением прекрасно справляются и старые средства даже в Java 1.4

А когда сделают ValueTypes вы также будете утверждать, не разрешая себе использовать структуры вместо классов?

Ну и покажи мне хотя бы одну такую библиотеку

https://github.com/wizzardo/tools/tree/master/modules/

Обычное деление на библиотеки, такое же как у Apache Commons. Кстати, никаких Java модулей я там не нашёл. Никаких module-info.java или Automatic-Module-Name в манифесте.

А разделение библиотеки JDK это что?

Это совсем другое и предназначено для кастомных сборок рантайма.

А когда сделают ValueTypes вы также будете утверждать, не разрешая себе использовать структуры вместо классов?

Причём тут ValueTypes и ваши фантазии о том, что я буду утверждать?