openlang

Два списка зависимостей, которым разрешено расходиться

Модульный Java-проект описывает зависимости дважды. Скрипт сборки говорит, какие артефакты скачать и на какой путь положить. module-info.java говорит, какие модули этот модуль requires. Ничто не заставляет эти списки совпадать, и они расходятся.

Отказы тут несимметричны. Модуль из requires, который сборка не поставляет, падает на компиляции с понятным сообщением. JAR, который сборка поставляет, но ни один requires не упоминает, просто недоступен вашему модулю, и компилятор так и пишет. Запутанный случай это зависимость без module-info.class. На пути модулей она становится автоматическим модулем, и имя берётся из записи Automatic-Module-Name в манифесте, если она есть, или выводится из имени JAR-файла, если её нет. Переименуйте файл, и имя, на которое указывает строка requires, может измениться.

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

Так что для меня скрипт сборки это источник правды о том, что существует, а module-info.java это заявление о том, к чему мне можно прикасаться. Разные задачи. Кто-нибудь вообще сверяет одно с другим без плагина?

Разговор продолжается 1

Следуя доводам
  1. Ссылка на ответ

    Кажется, оба списка можно оставить как есть, если никто не ждёт, что какой-то один расскажет всю историю. Файл сборки отвечает, что доступно, а module-info.java отвечает, что этот модуль читает. Когда они расходятся, компилятор в большинстве случаев уже об этом говорит. Закрепить стоит только имя автоматического модуля, и добавить Automatic-Module-Name в свои библиотеки до того, как от них кто-то начнёт зависеть, это маленькая привычка, которая тихо окупается.

Другие стороны того же вопроса

  1. Можно ли запускать зависимую работу после приостановки шага оболочки?

    Вопрос про правило супервизора, которое считает остановленный процесс завершённым. Шаг оболочки пишет входной файл, после нег…

    Ответы 3bashpython