Интерфейс ModuleFinder

Optional<ModuleReference> find(String name)

Находит ссылку на модуль с заданным именем.

ModuleFinder предоставляет согласованный вид модулей, которые он находит. Если find вызывается несколько раз для поиска одного и того же модуля (по имени), то он каждый раз возвращает один и тот же результат. Если модуль найден, то гарантируется, что он является членом набора модулей, возвращаемых методом findAll.

Set<ModuleReference> findAll()

Возвращает набор всех ссылок на модули, которые этот поиск может найти.

ModuleFinder предоставляет согласованный вид модулей, которые он находит. Если findAll вызывается несколько раз, то он каждый раз возвращает один и тот же (равный) результат. Для каждого элемента ModuleReference в возвращаемом наборе гарантируется, что find найдет ModuleReference , если вызовется для поиска этого модуля.

static ModuleFinder ofSystem()

Возвращает поиск модулей, который находит системные модули. Системные модули — это модули в образе среды выполнения Java. Поиск модулей всегда найдет java.base.

Если установлен менеджер безопасности, то вызывается его метод checkPermission для проверки, имеет ли вызывающая сторона разрешение RuntimePermission("accessSystemModules") для доступа к системным модулям.

static ModuleFinder of(Path... entries)

Возвращает поиск модулей, который находит модули в файловой системе, ища последовательность директорий и/или упакованных модулей. Каждый элемент в заданном массиве является одним из:

1. Путь к директории модулей.

2. Путь к главной директории распакованного модуля.

3. Путь к упакованному модулю.

Поиск модулей ищет каждый каталог, распакованный модуль или упакованный модуль в порядке индексов массива. Он находит первое вхождение модуля с заданным именем и игнорирует другие модули с тем же именем, которые появляются позже в последовательности.

Если элемент является путем к каталогу модулей, то каждый элемент в каталоге является упакованным модулем или главной директории распакованного модуля. Ошибка возникает, если каталог содержит более одного модуля с одинаковым именем. Если элемент является путем к каталогу, и этот каталог содержит файл с именем module-info.class, то каталог обрабатывается как распакованный модуль, а не каталог модулей.

Поиск модулей, возвращаемый этим методом, поддерживает модули, упакованные в файлы JAR. Файл JAR с module-info.class в своей главной директории или в версии записи в файле JAR с многократной версией является модульным файлом JAR и, таким образом, определяет явный модуль. Файл JAR, который не содержит module-info.class в своей главной директории, определяет автоматический модуль, как следует:

• Если файл JAR имеет атрибут "Automatic-Module-Name" в своём главном манифесте, то его значение является именем модуля. Имя модуля в противном случае выводится из имени файла JAR.

• version, и имя модуля, когда атрибут "Automatic-Module-Name" отсутствует, выводятся из имени файла JAR следующим образом:

  • Снимается суффикс ".jar".

  • Если имя соответствует регулярному выражению "-(\\d+(\\.|$))" , то имя модуля будет получено из подпоследовательности, предшествующей дефису первого вхождения. Подпоследовательность после дефиса анализируется как Version и игнорируется, если она не может быть проанализирована как Version.

  • Все неалфавитно-цифровые символы ([^A-Za-z0-9]) в имени модуля заменяются точкой ("."), все повторяющиеся точки заменяются одной точкой, а все начальные и конечные точки удаляются.

  • Например, файл JAR с именем "foo-bar.jar" выведет имя модуля "foo.bar" и без версии. Файл JAR с именем "foo-bar-1.2.3-SNAPSHOT.jar" выведет имя модуля "foo.bar" и версию "1.2.3-SNAPSHOT".

• Набор пакетов в модуле получается из элементов файла JAR, не являющихся каталогами, которые имеют имена, заканчивающиеся на ".class". Кандидатное имя пакета получается из имени с использованием символов до, но не включая, последнюю обратную косую черту. Все оставшиеся обратные косые черты заменяются точкой ("."). Если полученная строка является допустимым именем пакета, то она предполагается именем пакета. Например, если файл JAR содержит запись "p/q/Foo.class", то полученное имя пакета "p.q".

• Содержание записей, начинающихся с META-INF/services/ , предполагается конфигурационными файлами служб (см. ServiceLoader). Если имя файла (после META-INF/services/) является допустимым именем класса, то предполагается, что это полное имя класса типа сервиса. Записи в файле предполагаются полными именами классов провайдерских классов.

• Если файл JAR имеет атрибут Main-Class в своём главном манифесте, его значение является допустимым именем класса, и его пакет входит в набор пакетов, полученный для модуля, то значение является главным классом модуля .

Если ModuleDescriptor не может быть создан (с помощью API ModuleDescriptor.Builder) для автоматического модуля, то бросается FindException. Это может произойти, когда значение атрибута "Automatic-Module-Name" не является допустимым именем модуля, допустимое имя модуля не может быть получено из имени файла JAR, где файл JAR содержит .class в главной директории файла JAR, где запись в конфигурационном файле службы не является допустимым именем класса или его имя пакета не входит в набор пакетов, полученных для модуля.

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

Как и в случае с автоматическими модулями, содержимое упакованного или распакованного модуля может потребоваться сканировать, чтобы определить пакеты в модуле. Игнорируются ли скрытые файлы или нет, зависит от реализации, поэтому не указано. Если в главной директории найден файл .class (кроме module-info.class), то он предполагается классом в безымянном пакете, поэтому генерируется FindException.

Создаваемые этим методом поисковики ленивые и не проверяют немедленно, являются ли заданные пути к файлам каталогами или упакованными модулями. Следовательно, методы find или findAll будут завершаться ошибкой только в случае поиска каталога или упакованного модуля и возникновении ошибки.

static ModuleFinder compose(ModuleFinder... finders)

Возвращает поиск модулей, составленный из последовательности нуля или более поисков модулей. Метод find полученного поиска модулей будет находить модуль, вызывая метод find каждого поиска модулей в порядке индексов массива, пока модуль не будет найден или все поиски модулей не будут пройдены. Метод findAll полученного поиска модулей вернёт набор модулей, включающий все модули, найденные первым поиском модулей. Набор модулей будет включать все модули, найденные вторым или последующим поиском модулей, которые не найдены предыдущими поисками в последовательности.

При поиске модулей любые исключения или ошибки, генерируемые методами find или findAll базовых поисков модулей, будут переданы вызывающему методу find или findAll полученного поиска модулей.