JDK9：发生了非法reflection访问操作。 org.python.core.PySystemState
我正在尝试使用Java9（JDK9）运行DMelt程序（ http://jwork.org/dmelt/ ）程序，它给了我错误，例如：
WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.python.core.PySystemState (file:/dmelt/jehep/lib/jython/jython.jar) to method java.io.Console.encoding() WARNING: Please consider reporting this to the maintainers of org.python.core.PySystemState WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release 我该如何解决？ 我试图将-illegal-access = permit添加到脚本“dmelt.sh”的最后一行（我在Linux中使用bash），但这并没有解决这个问题。 我很沮丧。 很长一段时间我经常使用这个程序。 也许我永远不应该转向JDK9
解决这个问题的理想方法是
将此报告给org.python.core.PySystemState的维护者
并要求他们在未来修复这种反思性访问。
但是，如果默认模式允许非法reflection访问，则必须使其知晓，这样当人们不再是未来版本中的默认模式时，人们不会感到惊讶。
从邮件列表中的一个主题 ：
--illegal-access=permit
这将是JDK 9的默认模式。它打开每个显式模块中的每个包，以编码所有未命名的模块，即类路径上的代码，就像今天的
--permit-illegal-access一样。第一次非法reflection访问操作会发出警告，例如
--permit-illegal-access，但在该点之后不会发出警告。 此单个警告将描述如何启用进一步警告。
--illegal-access=deny
这将禁用所有非法reflection访问操作，但由其他命令行选项启用的操作除外，例如
--add-opens。 这将成为未来版本中的默认模式。
通过明智地使用--add-exports和--add-opens选项，可以像以前一样避免任何模式下的警告消息。
因此，当前可用的临时解决方案是使用--add-exports作为文档中提到的VM参数：
--add-exports module/package=target-module(,target-module)*
更新模块
export包export到target-module，而不管模块声明。target-module可以全部未命名，以导出到所有未命名的模块。
这将允许target-module访问package所有公共类型。 如果你想访问仍然封装的jdk内部类，你必须允许使用--add-opens参数进行深度reflection ：
--add-opens module/package=target-module(,target-module)*
更新模块
open包到target-module，无论模块声明如何。
在您的情况下，当前访问java.io.Console ，您只需将其添加为VM选项 –
--add-opens java.base/java.io=ALL-UNNAMED
另外，请注意上面链接的同一个post
当deny成为默认模式时，我希望至少有一个版本支持permit ，以便开发人员可以继续迁移他们的代码。 随着时间的推移， permit ， warn和debug模式将被删除， --illegal-access选项本身也将被删除。
因此，最好更改实施并遵循理想的解决方案。
DMelt似乎使用Jython，这个警告是Jython维护者需要解决的问题。 这里有一个跟踪它的问题： http ： //bugs.jython.org/issue2582
根据这篇文章http://bugs.jython.org/issue2582，Jython开发人员没有任何jdk9的实用解决方案。 前面的解释似乎很长，以确定应该做什么。 我只是希望jdk9的行为与jdk1.4 – 1.8完全相同，即完全无声。 JVM在后向可比性方面的优势。 我完全可以在JDK9中有其他选项，但新function不能破坏应用程序
真正的问题是JDK中的一个问题。 实际上没有非法访问，但JDK方法trySetAccessible行为不端。 希望在将来的JDK版本中修复此问题。
尝试解决以下答案链接