доклад Никиты Липского который отлично разъясняет чем прекрасен Jigsaw:

@Lelouch
вы привели прекрасный пример

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

вы такое в своей системе иметь точно не хотите

класс из aspectj в axiom-impl - это как раз такая история и, к слову, признанный косяк:
http://svn.apache.org/viewvc/webservices/axiom/branches/1.2.x/src/site/markdown/release-notes/1.2.23.md?view=markup&pathrev=1858616
который, вроде как, исправили в следующей версии (которая релизанется непонятно когда :( )

когда такая хрень во внешних библиотеках, разумных пути ровно два:
либо избавляться от такой библиотеки (к счастью, экосистема Java самая здоровая из всех ЯП, и достойную альтернативу можно найти почти всегда)
либо пинать ее разработчиков, чтобы чинили

это трудно, дорого, лениво: в итоге 65% из всех Java-проектов все еще на Java 8.

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

LelouchИ кстати, если на то пошло, то "из коробки" модульная система в Java вообще хреново решает проблему jar hell - просто не дает запустить приложение.
Если нужно (например из-за несовместимости в версиях) загрузить 2 разные версии классов - то нужно или "руками" мутить с ModuleLayer или опять же "ломать" модульную систему и переупаковывать классы.
Никаких стандартных решений модульная система для такой задачи не предоставляет.
Вы видите это как недостаток, я - как достоинство.

Lelouch1) Честно - не вижу никакого смысла, есть и другие способы решения проблемы jar hell
Вообще-то нет.
Вы конечно можете обложится анализаторами и организационными процедурами, которые дадут вам уверенность в том, что с зависимостями всё OK. Но уверенность - это не гарантия. Модули, как раз, дают гарантию , что приложение с определенными проблемами в зависимостях просто не стартует. Это гораздо лучше, чем получить мистику в рантайме.

Lelouch3) У меня есть проекты где я специально переопределяю классы сторонних библиотек, чтобы добавить им функциональность, которая не предусмотрена. Что я должен в таком случае с модулями делать? Предупреждая вопрос - стандартного способа расширения функционала автором в этом месте не предусмотрено.
OK. вы воспользовались нюансами classloader и/или Reflection, чтобы "взломать" API внешней библиотеки в нарушение принципов здорового ОOП. Вот только это, согласить, грязный путь. Да, очень редко, бывает, что другого путь нет. Признаю. Но это не аргумент против модулей. Вы, собственно, говорите, что модули плохи именно тем, что закрывают, лазейки, для закрытия которых, они, собственно, и придуманы :)

Lelouch1.1) Как же бедные разработчики до java 9 справлялись?)
1.2) Пока не будет описана как модули большая часть готовых библиотек (а затем не будут вычищены проблемы, как например приведенные выше) их использование будет постоянной головной болью
1.3) На мой вкус, сами по себе модули сделаны "не очень", как минимум в сравнении с теми же сборками в .net

3.1) Они делают эту лазейку чуть сложнее к использованию, но ничего не закрывают
3.2) КМК модули хорошо сделаны только для 1 цели - модуляризация самой java. Потому что в текущем виде они удобны только, если весь код решения контролируется разработчиком. Использование сторонних модулей сейчас скорее похоже на хождение по граблям - модулей или нет (большая часть библиотек) или могут быть собраны не так.

P.S. Если модули такие замечательные, почему ими практически никто не пользуется вот уже 3 года (или когда там java 9 вышла)? Почему не загнулся "страшный и костыльный" OSGi?

Ну а как бедные разработчики до Java 5 (~10 лет) справлялись без volatile?
Жить-то можно и без новых фич. Как-то.

Моя мысль в том, что модули полезная функциональность, которая позволяет улучшить приложение и открывает некоторые новые возможности.
Не правильно ее игнорировать. И я не согласен, с тем что модули сделаны "не очень". Правильно они сделаны.

И, по моему опыту, нет никакой особой проблемы их использовать, если у вас новый проект и сразу на Java 9+.

Проблема не в модулях, а в экосистеме Java
Вдруг выяснилось, что лазить в закрытые части API и таскать себе в JARы куски кода вместе оригинальными пакетами - это норма.
Типа, что не запрещено, то, значит, можно.

В итоге имеем, то что имеем.
Lukas Eder (создатель JOOQ) писал год назад на reddit :
I tried twice to modularise jOOQ. I fought a gazillion IDE bugs and it ended up not working because of transitive dependencies that had split packages. Postponed again for a few years...
B это 3 года после релиза Java 9.

Но опять же, это не проблема модулей, а проблема повсеместной "грязи" в библиотеках и фреймфорках.

Ну и OSGi не надо тоже идеализировать. За пределами экосистемы IBM, его тоже не особо видно.
В библиотеках тоже никто особо не утруждает себя "Bundle-" свойства в MANIFEST.MF добавлять
(хотя это не стоит усилий почти что совсем и спецификации, к слову, уже 20 лет!)
И мой личный опыт проектов с OSGi совершенно не позитивный: все то о чем Никита Липский рассказывал я видел своими глазами.