Отражение против инкапсуляции — автономно в модульной системе Java

 Class<?> owner = Class.forName("owner.Owner");
Method owned = owner.getDeclaredMethod(methodName);
owned.setAccessible(true);
owned.invoke(null);

 public: ✓   protected: ✗   default: ✗   private: ✗

 module owner {
    exports owner;
}

 public: ✓   protected: ✗   default: ✗   private: ✗

 module owner {
    exports owner to intruder;
}

Но результат такой же, как и при обычном экспорте — вторгающийся модуль может получить доступ только к открытым элементам:

 public: ✓   protected: ✗   default: ✗   private: ✗

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

Знание вторгающегося модуля может быть применимо в случае таких фреймворков, как Guice, но как только реализация скрывается за API (то, что команда JDK называет абстрактной отражающей структурой ; думаю, JPA и Hibernate), этот подход не срабатывает. Независимо от того, работает он или нет, явное присвоение имени вторгающемуся модулю в дескрипторе модуля-владельца может рассматриваться как ненадежное. С другой стороны, шансы на то, что владелец модуля уже в любом случае зависит от вторгающегося, потому что ему нужны какие-то аннотации или что-то в этом случае, и в этом случае мы не делаем вещи намного хуже.

Открытые пакеты

Теперь это становится интересным. Довольно недавним дополнением к модульной системе является способность модулей открывать пакеты только во время выполнения.

 module owner {
    opens owner;
}

Уступая:

 public: ✓   protected: ✓   default: ✓   private: ✓

Ухоженная! Мы убили двух зайцев одним выстрелом:

• Внедряющий модуль получил глубокий доступ ко всему пакету, позволяя использовать даже частные элементы.
• Эта экспозиция существует только во время выполнения, поэтому код не может быть скомпилирован для содержимого пакета.

Однако есть один недостаток: теперь все модули могут отображаться поверх открытого пакета. Тем не менее, в целом гораздо лучше, чем экспорт.

Квалифицированные открытые пакеты

Как и в случае экспорта и квалифицированного экспорта, существует также квалифицированный вариант открытых пакетов:

 module owner {
    opens owner to intruder;
}

Запустив программу, мы получаем тот же результат, что и раньше, но теперь только злоумышленник может достичь их:

 public: ✓   protected: ✓   default: ✓   private: ✓

Это дает нам тот же компромисс, что и между экспортом и квалифицированным экспортом, а также не работает для разделения между API и реализацией. Но есть надежда!

В ноябре Марк Рейнхольд предложил механизм, который позволял бы создавать код в модуле, для которого был открыт пакет, для передачи этого доступа третьему модулю. Возвращаясь к JPA и Hibernate, это точно решает эту проблему. Предположим следующий дескриптор модуля для владельца :

 module owner {
    // the JPA module is called java.persistence
    opens owner to java.persistence;
}

В этом случае механизм может быть использован следующим образом (цитируется почти дословно из предложения):

Менеджер сущностей JPA создается с помощью одного из методов Persistence::createEntityManagerFactory , которые обнаруживают и инициализируют подходящего поставщика постоянства, например, Hibernate. В рамках этого процесса они могут использовать метод addOpensвладельца клиентского модуля, чтобы открыть пакет owner Это будет работать, так как модуль ownerjava.persistence

Существует также вариант, когда контейнеры открывают пакеты для реализаций. В текущей сборке EA (b146) эта функция, похоже, еще не реализована, поэтому я не смог ее опробовать. Но это определенно выглядит многообещающе!

Открытый модуль

Если открытые пакеты были скальпелем, то открытые модули являются колыбелью. С его помощью модуль отказывается от любого контроля над тем, кто получает доступ к чему-либо во время выполнения, и открывает все пакеты для всех, как если бы для каждого из них было предложение открывания.

 opens

Это дает тот же доступ, что и индивидуально открытые пакеты:

 open module owner { }

Открытые модули можно считать промежуточным этапом на пути перехода от JAR-файлов к пути классов к полнофункциональным, сильно инкапсулированным модулям.

Обман класса путь

Теперь мы входим в менее модульную площадку. Как вы, наверное, знаете, public: ✓ protected: ✓ default: ✓ private: ✓
java Но путь класса не уходит, и JAR-файлы тоже нет. Мы можем использовать два трюка, если у нас есть доступ к командной строке запуска и мы можем перемещать артефакт (поэтому это не будет работать для модулей JDK).

Безымянный модуль

Во-первых, мы можем поместить модуль-владелец в путь к классам.

Как модульная система реагирует на это? Поскольку все должно быть модулем, система модулей просто создает один, безымянный модуль , и помещает в него все, что находит в пути к классам. Внутри безымянного модуля все очень похоже на сегодняшний день, и ад JAR продолжает существовать. Поскольку неназванный модуль является синтетическим, JPMS понятия не имеет, что он может экспортировать, поэтому он просто экспортирует все — во время компиляции и во время выполнения.

Если какой-либо JAR на пути к классу должен случайно содержать дескриптор модуля, этот механизм просто проигнорирует его. Следовательно, модуль-владелец понижается до обычного JAR, и его код заканчивается модулем, который экспортирует все:

 javac

Та-да! И не касаясь модуля-владельца, мы можем сделать это с модулями, над которыми у нас нет контроля. Небольшое предостережение: мы не можем требовать неназванного модуля, поэтому нет хорошего способа компилировать код из модуля-владельца из других модулей. Ну, может быть, предостережение не так уж и мало …

Автоматический модуль

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

 public: ✓   protected: ✓   default: ✓   private: ✓

Ницца. Центральное преимущество автоматических модулей перед неназванным модулем состоит в том, что модули могут требовать его, поэтому остальная часть приложения все еще может зависеть от него и компилировать его, в то время как злоумышленник может использовать отражение для доступа к своим внутренним компонентам.

Недостатком является то, что внутренние компоненты модуля становятся доступными во время выполнения для каждого другого модуля в системе. К сожалению, то же самое верно во время компиляции, если только нам не удастся скомпилировать соответствующий модуль-владелец и затем извлечь его дескриптор на пути к стартовой панели. Это сомнительно, сложно и подвержено ошибкам.

Командная строка Escape Люки

Так как мы все равно возимся с командной строкой, есть более чистый подход (возможно, я должен был рассказать вам об этом ранее): и public: ✓ protected: ✓ default: ✓ private: ✓
javacjava

 --add-opens

Это работает без изменения модуля-владельца и также применимо к модулям JDK. Так что да, гораздо лучше, чем безымянные и автоматические взломы модулей.

Выключатель инкапсуляции

Если все это кажется слишком громоздким, и вы просто хотите, чтобы оно работало для вашего приложения пути к java
--module-path mods
--add-modules owner
--add-opens owner/owner=intruder
--module intruder
--permit-illegal-accessдружно названный инкапсуляцией «kill switch» , является правильным аргументом командной строки для вас. С его помощью весь код в безымянном модуле может обращаться к другим типам независимо от любых ограничений, которые накладывает сильная инкапсуляция. Взамен вы получаете предупреждения о незаконном доступе и удушающем ощущении жизни в скрытое время: опция будет существовать только в Java 9 для облегчения миграции, поэтому вы просто купили себе два, три года.

Вот как запустить с владельцем на модуле и нарушителя на пути к классам:

 java
    --class-path mods/intruder.jar
    --module-path mods/owner.jar
    --add-modules owner
    --permit-illegal-access
    intruder.Intruder

И вот результат — обратите внимание, как предупреждения вписываются в мой тщательно созданный вывод:

 WARNING: --permit-illegal-access will be removed in the next major release
public:WARNING: Illegal access by intruder.Intruder (file:mods/intruder.jar) to method owner.Owner.publicMethod() (permitted by --permit-illegal-access)
 ✓   protected:WARNING: Illegal access by intruder.Intruder (file:mods/intruder.jar) to method owner.Owner.protectedMethod() (permitted by --permit-illegal-access)
 ✓   default:WARNING: Illegal access by intruder.Intruder (file:mods/intruder.jar) to method owner.Owner.defaultMethod() (permitted by --permit-illegal-access)
 ✓   private:WARNING: Illegal access by intruder.Intruder (file:mods/intruder.jar) to method owner.Owner.privateMethod() (permitted by --permit-illegal-access)
 ✓

Как я уже сказал, это работает, только если злоумышленник прибыл из неназванного модуля. Основанием для этого является то, что должным образом модульный код, то есть код, который находится в модулях, не должен нуждаться в таких взломах. Действительно, если мы поместим оба артефакта в путь к модулю, мы увидим, что флаг не используется (нет предупреждений, кроме первоначального), и доступ не выполняется, потому что внутренняя структура owner

 java
    --module-path mods
    --add-modules owner
    --permit-illegal-access
    --module intruder

WARNING: --permit-illegal-access will be removed in the next major release
public: ✗   protected: ✗   default: ✗   private: ✗

Резюме

Оки, все еще помнишь все, что мы делали? Нет? Сводная сводная таблица на помощь!

механизм	доступ	скомпилировать доступ	доступ к отражению	Комментарии
экспорт	дескриптор	весь код> общедоступный	весь код> общедоступный	делает API общедоступным
квалифицированный экспорт	дескриптор	указанные модули> общедоступные	указанные модули> общедоступные	нужно знать вторгающиеся модули
открытая упаковка	дескриптор	никто	весь код> частный
квалифицированный открытый пакет	дескриптор	никто	указанные модули> частные	могут быть перенесены в модули реализации
открытый модуль	дескриптор	никто	весь код> частный	одно ключевое слово, чтобы открыть все пакеты
неназванный модуль	командная строка и артефакт	все немодули> общедоступные	весь код> частный
автоматический модуль	командная строка и артефакт	весь код> общедоступный	весь код> частный	требует возиться с артефактом
флаги командной строки	командная строка	никто	весь код> частный
Аварийная кнопка	командная строка	никто	безымянный модуль> частный

Вау, мы действительно прошли через множество вариантов! Но теперь вы знаете, что делать, если перед вами стоит задача разбить модуль на рефлексию. Таким образом, я думаю, что подавляющее большинство случаев использования может быть покрыто путем ответа на один вопрос:

Это ваш собственный модуль?

• Да ⇝ Открытые пакеты (возможно, квалифицированные) или, если их слишком много, весь модуль.
• Нет ⇝ Используйте флаги командной строки --add-opens--permit-illegal-access