Это третье издание серии. Для второго издания нажмите здесь.
Дескрипторы модуля
Модули определяются дескрипторами модулей. Итак, давайте посмотрим на пример дескрипторов модулей.
Теперь, взглянув на дескрипторы модуля выше для java.base, он находится в файле с именем module-info.java. Самая важная часть module-info.java — это интеграция имени модуля. В этом случае по ключевому слову модуля, за которым следует имя java.base. В теле объявления модуля у нас могут быть дополнительные операторы, описывающие дополнительную информацию о самом модуле. В случае с java.base мы знаем, что некоторые пакеты должны быть общедоступными. Теперь по умолчанию любой пакет внутри модуля не является публичным. Он недоступен для других модулей. Если вы хотите предоставить другим модулям доступ к некоторым пакетам, вам необходимо их экспортировать. Это то, что мы видим выше. Для каждого пакета, который вы хотите открыть из своего модуля для внешнего мира, существует оператор экспорта. Обратите внимание, что нет заявления, относящегося к внутренним пакетам. Это связано с тем, что по умолчанию все пакеты, которые не указаны как экспортированные, инкапсулируются в модуль и недоступны для других модулей.
Возьмем для примера модуль java.sql. Этот модуль имеет две зависимости. Мы экспортируем некоторые пакеты из java.sql. Самое интересное находится в зависимостях. Вы добавляете оператор require в модуль. Между оператором export и оператором require есть одно большое различие, которое я хочу подчеркнуть, потому что оно может быть не сразу очевидно. Оператор экспорта принимает в качестве параметра имя пакета, тогда как оператор require принимает в качестве параметра имя модуля. Итак, модули экспортируют пакеты, но требуют других модулей.
Теперь мы знаем, как создавать дескрипторы модулей.
Разрешение модуля
Когда мы компилируем и запускаем приложение Java 9, оно начинается с так называемого корневого модуля, который указывается пользователем. Цель процесса разрешения модуля — получить набор разрешенных модулей, необходимых для запуска приложения. В этот набор должны входить все модули, необходимые для запуска приложения, но не более того. Конечно, теперь, когда мы начинаем процесс разрешения, корневой модуль является частью результирующего набора модулей. Далее происходит то, что модульная система проверяет дескриптор модуля этого модуля и все его зависимости от набора разрешенных модулей. Теперь процесс рекурсивно продолжается поиском зависимостей нового модуля, добавленного в набор. Поиск останавливается, когда больше нет зависимостей от модуля в наборе к другим модулям, что означает, что мы закончили с разрешением модуля и у нас есть наш окончательный набор модулей для запуска приложения.
Процесс разрешения модулей — один из наших главных союзников в поиске надежных приложений. Он проверяет правильность пути к модулю, который мы предоставляем. Если какой-либо модуль отсутствует, он обнаружит это. Разрешение модуля происходит как во время компиляции, так и во время выполнения, поэтому, если у вас есть неполный путь к модулю во время компиляции, вы также будете предупреждены компилятором, а при запуске вашего приложения, если что-то пойдет не так в процессе разрешения модуля, вы получите ошибка раньше времени. Он применяется как к модулям приложения, так и к модулям платформы. После того, как преобразователь будет выполнен, вы получите полное представление обо всех модулях, необходимых для запуска приложения. Он даже отклоняет несколько версий одного и того же модуля, если они встречаются в каталоге пути к модулю. Мы можем запускать разрешение несколько раз для нескольких корневых модулей и объединять полученные наборы модулей в один набор.
В следующей главе мы рассмотрим специальное отношение, называемое удобочитаемостью.
Нажмите здесь, чтобы перейти к следующему выпуску.
источник:
https://www.geekboots.com
https://www.pluralsight.com
