Модульная система оказывает в основном следующее влияние на код:
- Доступ к пакету возможен только из одного модуля (вложенные пакеты рассматриваются как отдельные, поэтому, даже если пакет
java.util находится в модуле java.base, пакет java.util.logging может находиться в модуле java.logging)
- Доступ к открытым полям и методам кода возможен только в экспортированных пакетах других модулей. Это верно даже для отражения (то есть
java.lang.reflect.AccessibleObject.setAccessible(boolean) работает только для кода в том же модуле)
Весь код, находящийся на пути к классам, живет вместе в «неназванном» модуле.
Весь код на модульном пути живет в своих собственных «именованных» модулях.
Вы должны различать два случая:
Если вы не добавите module-info.java в свой проект, ваш проект будет частью безымянного модуля и сможет видеть весь другой код в безымянном модуле, плюс код в java.base и код в модулях в java.se корневой модуль. В основном это означает, что w.r.t. код в classpath, все по-прежнему работает как в Java 8, так что вы просто должны поместить свои зависимости в classpath.
Если в вашем проекте есть module-info.java, ваш проект будет находиться в своем собственном именованном модуле и сможет видеть код только в java.base и других именованных модулях, ссылки на которые указаны с помощью «require» в модуле-info.java. Поскольку именованные модули находятся только через путь к модулю, вы должны поместить свои зависимости в путь к классам. Это даже работает для jar-файлов, созданных до java 9, которые получают имя модуля, полученное из имени файла .jar (в этом случае они называются «автоматическим» модулем).
JRE всегда находится на пути к модулю, поэтому его внутренний код не может быть доступен даже из кода на пути к классам.
Существует один особый случай: если у вас есть module-info.java в вашем проекте и есть тестовый код в вашем проекте, вы обычно не хотите упоминать тестовые зависимости, такие как junit в module-info.java. Для этого есть два решения:
Создать выделенный тестовый модуль. Это всегда было условием для проектов, основанных на OSGI. Недостатком является то, что вы можете использовать только общедоступные API в своих тестах
Решение, используемое maven: поместите свои тестовые зависимости в путь к классам. При компиляции тестового кода maven добавляет параметры командной строки, которые позволяют коду в названном модуле читать безымянный модуль (что невозможно через module-info.java).
В Eclipse Oxygen решение maven оказалось невозможным, поскольку в нем нет понятия, какой код является тестовым кодом, но это было реализовано в следующем выпуске Eclipse Photon (4.8), который выйдет в июне. Вы можете уже работать с (полнофункциональными) вехами, начиная с http://download.eclipse.org/eclipse/downloads/.. Если вы обнаружите какие-либо ошибки, сообщите о них в https://bugs.eclipse.org/bugs/.