Java modules

Question 1

Определение имени автоматического модуля

Answer 1

Имя модуля либо берется из свойства Automatic-Module-Name манифеста джарника либо при его отсутствии определяется из имени файла джарника. При этом удаляется расширение, версия (версия это последовательность цифр и точек) и все что после нее, также все не цифробуквенные символы преобразуются в точки, лишние точки убираются

Question 2

Виды модулей

Answer 2

1) named module - имеет module-info файл и находится на module path
2) автоматический модуль- обычный джар без module-info файла который находится на module path- при этом он видит Unnamed модули. Он нужен для того чтобы в рамках совместимости любой джарник мог использоваться как модуль. Для такого модуля генерится неявный Module-info который экспортит все пакеты
3) unnamed module- обычный джарник на класспасе (не на модуль пасе). Даже если он содержит module-info файл он игнорируется. Работает по старинке, ничего не экспортит модулям, зато сам видит все джарники и на класспасе и на модуль пасе

Т.е. модули могут брать пакеты только из Named и automatic модулей, а старые джарники (unnamed modules) видят все и работают по страинке- для них модулей не существует.

Question 3

OOTB java модули

Answer 3

java. base- Collections, Math, IO,NIO,concurrency
java. sql, java.xml, java.logging, java.management, java.se, java.security, java.smartcardio,java.rmi, java.net, java.instrument, java.compiler,java.scripting,java.naming
java. desktop - awt, swing

Question 4

Стратегии миграции на модульную систему

Answer 4

Вначале создаем схему зависимостей проекта, где проекты не имеющие зависимости внизу, те которые от них зависят вверху и выстраиваем их в одну колонку.
1) bottom-up миграция (наиболее эффективна когда мы котролируем все зависимости)
начинаем мигрировать с нижних зависимостей, добавляем в них module-info файл и перемещаем в module path- Это работает так как уже симгрированные зависимости всегда будут иметь свои зависимости как модули, а все что выше так как будет на класс пасе будет Unnamed module и будет видеть и уже смигрированные и еще не смигрированные зависимости
2) top-down миграция (эффективна когда мы не котролируем все зависимости)
-перемещаем все зависимости на module path и начинаем мигрировать начиная с верхней зависимости- при этом те что мы смигрировали будут named модулями, остальные automatic модулями
3) Декомпозиция.
Разделения одного проекта на модули- стоит только учитывать что циклические зависимости не скомпилируются.

Question 5

Разбиение на Service/Provider/Consumer модули

Answer 5

ServiceProviderInterface- определяет API для сервис провайдера, но не реализует его. Экспортит данный АПИ.
ServiceLocator - импортит API сервис провайдера, находит его имплементации (uses) и экспортит методы для работы с имплементациями не раскрывая деталей.
Consumer- ничего не знает о имплменетациях, экспортит методы из сервис локатора и API сервис провайдера
ServiceProvider - независимо реализует API сервис провайдера (provides with)-может быть только одна имплементация каждого интерфейса на модуль
Service- это совокупность СервисЛокатора и СервисПровайдерИнтерфейса

Можно уменьшать количество модулей за счет объединения ролей (например в одном модуле локатор и консумер или консумер и сервис провайдер, но для корректной работы Сервис Локатора все равно нужно использовать provides и uses)

Question 6

ServiceLoader

Answer 6

java.util класс для создания сервис локаторов
Имеет статический класс ServiceLoader ServiceLoader.load(Class) который ищет имплементации переданного сервиса (чаще интерфейс или абстрактный класс) и возвращает сервислоавдера с найденными имплементациями.
ServiceLoader имплементит Iterable поэтому его можно либо прокрутить в цикле либо преобразовать в стрим Stream stream()
Каждый провайдер в стриме имеет метод get() возвращающий инстанс имплементирующий сервис.
Например ServiceLoader.load(Class).stream().map(Provider::get)

Также имеет метод findFirst() возвращающий первую имплементацию