Я могу только сказать вам мнение моей организации по этому поводу. Мы находимся в процессе перехода к модулям для каждого проекта, над которым мы работаем. То, что мы создаем, - это в основном микросервисы + некоторые клиентские библиотеки. Для микросервисов переход на modulesкакой-то более низкий приоритет: код там уже каким-то образом изолирован в контейнере докера, поэтому «добавление» туда модулей не кажется (нам) очень важным. Эта работа продвигается медленно, но это низкий приоритет.
С другой стороны, клиентские библиотеки - это совсем другая история. Я не могу сказать вам, какой беспорядок у нас бывает. Я объясню один момент, который раньше ненавидел jigsaw. Вы предоставляете клиентам интерфейс, которым они могут пользоваться. Автоматически , что interfaceэто public- подвергается воздействию света. Обычно то, что я делаю, - это некоторые package-privateклассы, которые не доступны клиентам, использующим этот интерфейс. Я не хочу, чтобы клиенты использовали это, это внутреннее. Звучит неплохо? Неправильно.
Первая проблема заключается в том, что когда эти package-privateклассы растут и вам нужно больше классов, единственный способ сохранить все скрытым - это создать классы в одном пакете:
package abc:
-- Usage.java
-- HelperUsage.java
-- FactoryUsage.java
....
Когда он растет (в нашем случае растет), эти пакеты становятся слишком большими. Вы говорите, переход на отдельный пакет? Конечно, но тогда так HelperUsageи FactoryUsageбудет, publicи мы с самого начала старались этого избежать.
Проблема номер два: любой пользователь / вызывающий наших клиентов может создать пакет с тем же именем и расширить эти скрытые классы. С нами такое случалось уже несколько раз, веселые времена.
modulesрешает эту проблему красивым способом: publicне действительно public больше; Я могу получить friendдоступ через exports toдирективу. Это значительно упрощает жизненный цикл нашего кода и управление. И мы уходим из ада классов. Конечно maven/gradle, в основном справляйтесь с этим для нас, но когда возникает проблема, боль будет очень реальной. Могло быть много других примеров.
Тем не менее, переход (все еще) непростой. Прежде всего, все в команде должны быть согласованы; во-вторых, есть препятствия. Два самых важных, которые я до сих пор вижу: как разделить каждый модуль, в зависимости от чего конкретно? Однозначного ответа у меня пока нет. Во-вторых split-packages, «один и тот же класс экспортируется разными модулями». Если это происходит с вашими библиотеками, есть способы смягчить его; но если это внешние библиотеки ... не что легко.
Если вы зависите от jarAи jarB(отдельных модулей), но они оба экспортируют abc.def.Util, вас ждет сюрприз. Однако есть способы решить эту проблему. Как-то больно, но разрешимо.
В целом, с тех пор, как мы перешли на модули (и до сих пор делаем), наш код стал намного чище. И если ваша компания использует код прежде всего, это имеет значение. С другой стороны, я был вовлечен в компании, где старшие архитекторы считали это «слишком дорогим» и «безрезультатным».