Раздел 2.1 объясняет, что делает гипотетическое приложение, из каких типов оно состоит и что входит в его сферу ответственности. Система модулей появляется в разделе 2.2, где обсуждается, как организовать файлы и папки, описать модули, скомпилировать и запустить приложение. Это краткое знакомство продемонстрирует многие из основных механизмов системы модулей, а также ряд случаев, когда базовых функций не хватает для модуляризации сложного приложения, — тема, которая обсуждается в разделе 2.3. Вы можете найти приложение онлайн по ссылкам www.manning.com/books/the-java-module-system и github.com/CodeFX-org/demo-jpms-monitor. Ветка master содержит вариант, описанный в разделе 2.2.
Однако для того, чтобы по-настоящему понять проблемы, от которых система модулей собирается избавиться, и оценить предлагаемые решения, требуется нечто большее. Ознакомление со следующими концепциями и опыт работы с большими приложениями упростит понимание возможностей системы модулей и их преимущества и недостатки:
• принципы работы JVM, в частности загрузчика классов;
• проблемы, которые вызывает этот механизм (вспомните JAR-ад);
• более продвинутые API Java, такие как загрузчик сервисов и API рефлексии;
• инструменты сборки, такие как Maven и Gradle, и построение с их помощью проекта;
• способы модуляризации программных систем.
Резюме
• Систему программного обеспечения можно представить в виде графа, который часто показывает (не)желаемые свойства системы.
• Java не поддерживает графы на уровне JAR-файлов. Это приводит к различным проблемам, среди которых можно выделить JAR-ад, ручную проверку безопасности и неудобства сопровождения.
• Система модулей платформы Java существует для того, чтобы обеспечить понимание графов Java, что вносит в язык модульность на уровне артефактов. Самые важные ее цели — надежные настройка и инкапсуляция, так же как улучшение безопасности, удобства сопровождения и производительности.
• Все это достижимо благодаря вводу модулей — грубо говоря, JAR-файлов с дополнительным дескриптором. Компилятор и среда выполнения интерпретируют описанную информацию, чтобы построить граф зависимостей и предоставить обещанные преимущества.
Целью модулей не является и создание динамических графов, где артефакты возникают или исчезают по мере работы программы. Тем не менее такую систему можно реализовать с помощью уже существующей расширенной функции — слоев (см. раздел 12.4).
Некоторые функции, работавшие раньше, перестанут работать в Java 9, и использование отдельных структур потребует чуть-чуть больше усилий, нежели раньше.
Можно сравнить это с тем, насколько сильно и статически типизируемый язык требует увеличения объема работы, чем динамически типизируемый, — как минимум во время написания кода. Все эти типы и обобщения — разве нельзя просто взять Object и использовать его повсюду? Конечно, можно, но готовы ли вы отказаться от безопасности, которую предоставляет система типов, ради того, чтобы просто приложить чуть меньше усилий при написании кода? Мне так не кажется.
Класс, являющийся приватным в модуле, должен быть таким же приватным, как поле, которое приватно в классе. Другими словами, границы модуля должны определять не только видимость классов и интерфейсов, но и их доступность
Определение: масштабируемая платформа
Благодаря модульности JDK можно отобрать нужный функционал и создать среду выполнения, состоящую только из необходимых модулей.
Это делает Java центральной фигурой при выборе платформы для небольших устройств и контейнеров
До Java 9 JAR-файлы с одними и теми же классами не рассматривались как конфликтующие. Вместо этого процесс выполнения выбирал произвольный класс, затеняя другие, что приводило к сложностям, описанным в подразделе 1.3.2. Начиная с Java 9, компилятор и виртуальная машина стали распознавать эти и другие неопределенности, что позволяет выявлять проблему на ранних сроках.
Определение: надежная настройка
В совокупности это делает настройку системы более надежной, чем раньше, поскольку лишь очень хорошо сформированные настройки запуска пройдут данный тест. Если они сделают это, то виртуальная машина сможет превратить концептуальный граф зависимостей в граф модуля, который заменит комок грязи на структурированное изображение работающей системы — так же, как сделали бы мы сами
Сосуществование пути класса и пути модуля и соответствующая обработка ими модульных артефактов — ключ к пониманию больших приложений с точки зрения системы модулей. Глава 8 подробно исследует эту важную тему.
Цель таких принципов, как разделение ответственности и инверсия зависимостей, — распутать граф. Если проигнорировать их, то система превратится в хаос, где ничто не может быть изменено без потенциального вывода из строя чего-то никак с этим не связанного. Если же следовать им — система станет хорошо организованной.