LINUX.ORG.RU
ФорумTalks

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

 , , , ,


1

3

С момента появления Java модулей в Java 9 прошло уже достаточно времени, но какой-то серьёзной заинтересованности в их использовании не заметно. И действительно, кому нужны Java модули без разрешения версий? Strong encapsulation - конечно хорошо, но лишь ради этого переводить проект на Java модули или модулизировать новый проект как-то неоправданно. Старый добрый Classpath прекрасно работает и так.

Транзитивные зависимости в Maven, Gradle и в прочих SBT могут приводить к конфликтам версий только из-за невозможности разрешить их на уровне Classpath. В итоге Maven, Gradle и компания просто оставляют какую-то одну версию, в надежде, что всё будет работать и так. А ведь они могли бы оставлять все версии транзитивных зависимостей, которые изолированно использовались бы другими зависимостями на уровне Java модулей.

https://www.youtube.com/watch?v=hEnvRXNyDgI&t=2042s

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

Дополнение:

Вот уже начались пляски с бубнами вокруг разрешения версий модулей в виде Jigsaw Layers:

https://www.youtube.com/watch?v=KVdZyj7_KVM

Презентация этого доклада:
https://downloads.ctfassets.net/oxjq45e8ilak/65DDLtkCvCIIUE0AouKYwQ/c773104e9...

Демонстрационный проект Никиты Липского на GitHub-е:
https://github.com/pjBooms/Jigsaw-Layers-Example

Кстати, у меня не получилось запустить этот код так, чтобы он печатал две строки одновременно. Печатает лишь одну.

★★★★★

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

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

bvn13 ★★★★★ ()

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

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

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

Deleted ()
Ответ на: комментарий от Deleted

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

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

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

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

bbk123 ★★★★★ ()
Ответ на: комментарий от bbk123

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

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

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

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

Deleted ()

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

Legioner ★★★★★ ()
Последнее исправление: Legioner (всего исправлений: 2)
Ответ на: комментарий от Deleted

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

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

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

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

bbk123 ★★★★★ ()
Ответ на: комментарий от Legioner

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

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

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

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

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

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

bbk123 ★★★★★ ()
Ответ на: комментарий от Deleted

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

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.

bbk123 ★★★★★ ()
Ответ на: комментарий от bbk123

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

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

Legioner ★★★★★ ()
Последнее исправление: Legioner (всего исправлений: 2)
Ответ на: комментарий от Legioner

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

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

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

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

bbk123 ★★★★★ ()

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

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

foror ★★★★ ()
Последнее исправление: foror (всего исправлений: 2)
Ответ на: комментарий от foror

Апачевские 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-полная проблема, а просто заранее посторенный граф зависимостей с конкретными связями, а не диапазонами. Причём в этом случае нет никаких конфликтов с транзитивными зависимостями.

bbk123 ★★★★★ ()

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

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

vtVitus ★★★★★ ()
Ответ на: комментарий от bbk123

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

vtVitus ★★★★★ ()
Ответ на: комментарий от bbk123

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

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

foror ★★★★ ()
Последнее исправление: foror (всего исправлений: 1)
Ответ на: комментарий от vtVitus

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

bbk123 ★★★★★ ()
Ответ на: комментарий от foror

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

bbk123 ★★★★★ ()
Ответ на: комментарий от bbk123

Jigsaw

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

Модульность

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

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

vtVitus ★★★★★ ()
Ответ на: комментарий от vtVitus

Это был проект 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.


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

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

bbk123 ★★★★★ ()
Ответ на: комментарий от bbk123

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

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

iZEN ★★★★★ ()
Последнее исправление: iZEN (всего исправлений: 1)
Ответ на: комментарий от bbk123

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

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

iZEN ★★★★★ ()
Ответ на: комментарий от iZEN

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

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

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

bbk123 ★★★★★ ()
Последнее исправление: bbk123 (всего исправлений: 2)
Ответ на: комментарий от bbk123

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

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

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

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

foror ★★★★ ()
Последнее исправление: foror (всего исправлений: 2)
Ответ на: комментарий от bbk123

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

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

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

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

iZEN ★★★★★ ()
Последнее исправление: iZEN (всего исправлений: 1)
Ответ на: комментарий от foror

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

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

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

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

bbk123 ★★★★★ ()
Ответ на: комментарий от iZEN

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

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

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

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

bbk123 ★★★★★ ()
Ответ на: комментарий от iZEN

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

bbk123 ★★★★★ ()
Ответ на: комментарий от bbk123

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

iZEN ★★★★★ ()
Последнее исправление: iZEN (всего исправлений: 1)
Ответ на: комментарий от iZEN

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

bbk123 ★★★★★ ()
Ответ на: комментарий от bbk123

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

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

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

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

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

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

foror ★★★★ ()
Последнее исправление: foror (всего исправлений: 3)
Ответ на: комментарий от foror

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

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


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

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

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

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

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

bbk123 ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.