Как в Java 17 не прибегать к --add-opens?
Начиная с Java 17
--illegal-accessфактически устарело https://openjdk.java.net/jeps/403
Любое использование этой опции, будь то с разрешением, предупреждением, отладкой или отказом, не будет иметь никакого эффекта, кроме выдачи предупреждающего сообщения. Мы планируем полностью удалить параметр --illegal-access в следующем выпуске.
Из-за этого, используя сборки раннего доступа openjdk17, я вижу проблему с https://github.com/FasterXML/jackson-databind/issues/3168 . Мне кажется, что они выступают за использование и изо всех сил пытаются представить себе целостное «решение».
Я бы не хотел добавлять
--add-opens потому что если это не
jackson, это следующая зависимость. Я не хочу менять аргументы JVM в разных средах из-за изменений зависимостей. Как мне этого избежать?
3 ответа
Из этой статьи кажется, что можно не прибегать к--add-opensпутем экспорта модулей во время выполнения с помощью методов библиотеки Burningwave Core:
-
org.burningwave.core.assembler.StaticComponentContainer.Modules.exportAllToAll() -
org.burningwave.core.assembler.StaticComponentContainer.Modules.exportPackageToAllUnnamed("java.base","java.lang")
Вы этого не сделаете, внутренние компоненты JDK инкапсулированы по какой-то причине.
...
...
Хорошо, они уже ушли?
Вы можете использовать Overlord от Маккензи Скотт, чтобы делать различные невероятно опасные вещи, которые никто никогда не должен делать, включая, помимо прочего:
- Создание объектов без вызова их конструкторов
- Приведение значений к несовместимым типам
- Управление памятью напрямую, и действительно,
- Принудительный доступ к внутренним компонентам JDK.
Точнее, увидеть (вернее, не увидеть)Overlord.breakEncapsulation(Class, Class, boolean)иOverlord.allowAccess(Class, Class, boolean).
Как указано в этом ответе, вы можете решить, вызвав метод
org.burningwave.core.assembler.StaticComponentContainer.Modules.exportAllToAll() перед загрузкой класса, который является причиной исключения.