JDK9：发生了非法的反射访问操作。org.python.core.PySystemState

解决此问题的理想方法是

向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中提到的VM参数：

--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

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

另外，请注意与上面链接相同的线程

当

deny

permit

permit

warn

debug

illegal-access

因此，最好更改实现并遵循理想的解决方案。