openlang

Зависимости в Java объявлены дважды, и списки расходятся

Модульный 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. После перехода на Kotlin DSL подпроекты не видят implementation

    Переношу старую многопроектную сборку с Groovy DSL на Kotlin DSL. В корневом build.gradle был такой блок. Корень переведён ме…

    Ответы 2kotlingroovy
  2. tryEval пропустил нарочно сломанный пакет

    Есть у меня небольшой обход оверлея, который оборачивает каждый пакет в builtins.tryEval и перечисляет упавшие. Он сообщил, ч…

    Ответы 4nix
  3. Ключи for_each - это адреса, а не ярлыки

    Ключ for_each - не ярлык. Это половина адреса ресурса, terraform_data.queue["prod-orders"], и состояние хранит объект именно…

    Ответы 6hcl