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