JDK9: Произошла незаконная операция рефлексивного доступа. org.python.core.PySystemState

Ответ 1

Идеальный способ разрешить это будет

сообщить об этом разработчикам org.python.core.PySystemState

и попросить их исправить такой рефлексивный доступ в будущем.

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

Из одного из потоков в списке рассылки:

--illegal-access=permit

Это будет режим по умолчанию для JDK 9. Он открывает каждый пакет в каждый явный модуль для кодирования во всех неназванных модулях, то есть код на путь класса, так же, как --permit-illegal-access.

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

--illegal-access=deny

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

Предупреждающие сообщения в любом режиме можно избежать, как и прежде, разумным использованием опций --add-exports и --add-opens.

Следовательно, текущим временным решением является использование --add-exports в качестве аргументов виртуальной машины, как указано в docs:

--add-exports module/package=target-module(,target-module)*

Обновляет модуль до export пакета до target-module, независимо от того, объявление модуля. target-module может быть всем без имени для экспорта в все неназванные модули.

Это позволит target-module получить доступ ко всем общедоступным типам в package. Если вы хотите получить доступ к внутренним классам jdk, которые все еще будут инкапсулированы, вам нужно будет разрешить глубокое отражение с помощью аргумента --add-opens как:

--add-opens module/package=target-module(,target-module)*

Обновляет модуль до open пакета до target-module, независимо от модуля декларация.

В вашем случае, чтобы получить доступ к java.io.Console, вы можете просто добавить это как опцию VM -

--add-opens java.base/java.io=ALL-UNNAMED

Также обратите внимание на тот же поток, что и ссылка выше

Когда deny становится режимом по умолчанию, я ожидаю, что permit останется поддерживаемым хотя бы для одной версии, чтобы разработчики могли продолжать переносить свой код. Режимы permit, warn и debug со временем будут удалены, как и сама опция --illegal-access.

Поэтому лучше изменить реализацию и следовать идеальному решению.

Ответ 2

DMelt, похоже, использует Jython, и это предупреждение - это то, к чему должны обратиться адресаты Jython. Существует проблема, отслеживающая его здесь: http://bugs.jython.org/issue2582

Ответ 3

У разработчиков Jython нет практического решения для jdk9, согласно этому сообщению http://bugs.jython.org/issue2582. Предыдущее объяснение кажется очень длинным, чтобы выяснить, что нужно сделать. Я просто хочу, чтобы jdk9 вел себя точно так же, как jdk1.4 - 1.8, то есть полностью молчал. Сила JVM в обратной сопоставимости. Я полностью уверен, что у меня есть дополнительные опции в JDK9, но новые функции не могут сломать приложения.

Ответ 4

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

попробуйте решить ниже ответ ссылка

Ответ 5

Возможно, исправление ниже работает и для java 9:

В моем случае версия java open jdk была 10.0.2 и получила ту же ошибку (произошла недопустимая операция доступа с отражением). Я обновил maven до версии 3.6.0 в Linux, и проблема исчезла.

Ответ 6

Все эти предупреждения по-прежнему отображаются даже в новом JDK12 (сборки с ранним доступом (декабрь 2018 г.)). Смотрите обсуждение на форуме проекта DatMelt