JDK9：发生了非法反射访问操作。 org.python.core.PySystemState [英] JDK9: An illegal reflective access operation has occurred. org.python.core.PySystemState

问题描述

我正在尝试运行DMelt程序（ http://jwork.org/dmelt/ ）程序使用Java9（JDK9），它给我错误，如：

I'm trying to run DMelt programs (http://jwork.org/dmelt/) program using Java9 (JDK9), and it gives me errors such as:

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

How can I fix it? I was trying to add –illegal-access=permit to the last line of the script "dmelt.sh" (I'm using bash in Linux), but this did not solve this problem. I'm very frustrating with this. I was using this program very often, for very long time. Maybe I should never move to JDK9

推荐答案

理想解决这个问题的方法是

The ideal way to resolve this would be to

向org.python.core.PySystemState的维护者报告此内容

并要求他们继续修复这种反射访问。

and asking them to fix such reflective access going forward.

但是，如果默认模式允许非法反射访问，那么
必须要知道这一点，以便人们在
这不再是默认模式时不会感到惊讶未来发布。

If the default mode permits illegal reflective access, however, then it's essential to make that known so that people aren't surprised when this is no longer the default mode in a future release.

来自其中一个邮件列表上的主题：

--illegal-access=permit

这将是 JDK 9的默认模式。它打开每个包
每个显式模块在所有未命名的模块中编码，即
类路径上的代码，就像 - permit-illegal-access 今天一样。

This will be the default mode for JDK 9. It opens every package in every explicit module to code in all unnamed modules, i.e., code on the class path, just as --permit-illegal-access does today.

第一次非法反射访问操作导致警告发出
，与 - permit-illegal-access ，但在此之后没有发出
的警告。此单一警告将描述如何启用
进一步警告。

The first illegal reflective-access operation causes a warning to be issued, as with --permit-illegal-access, but no warnings are issued after that point. This single warning will describe how to enable further warnings.

--illegal-access=deny

这会禁用所有非法反射访问操作，除了
由其他命令行选项启用的那些，例如 - add-opens 。
此将成为未来版本中的默认模式。

任何模式下的警告消息可以像以前一样，通过明智地使用 - add-exports 和 - add-opens 来避免选项。

Warning messages in any mode can be avoided, as before, by the judicious use of the --add-exports and --add-opens options.

因此，现有的临时解决方案是使用 - add-exports 作为 docs ：

Hence a current temporary solution available is to use --add-exports as the VM arguments as mentioned in the docs :

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

将模块更新为 export 打包到 target-module ，无论
模块声明如何。 target-module 可以全部未命名导出到
所有未命名的模块。

Updates module to export package to target-module, regardless of module declaration. The target-module can be all unnamed to export to all unnamed modules.

这将允许目标模块访问包中的所有公共类型。如果你想访问仍然被封装的jdk内部类，你必须使用 - add-opens 深度反射 >参数：

This would allow the target-module to access all public types in package. In case you want to access the jdk internal classes which would still be encapsulated, you would have to allow a deep reflection using the --add-opens argument as:

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

将模块更新为 open 打包到目标模块，无论模块
声明。

Updates module to open package to target-module, regardless of module declaration.

在您的情况下，当前访问 java.io.Console ，您只需将其添加为VM选项 -

In your case to currently access the java.io.Console, you can simply add this as a VM option -

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

---

另外，请注意上面链接的同一个帖子

---

Also, note from the same thread as linked above

当 deny 成为默认模式时，我希望 permit 至少保持一个版本的支持，以便开发人员可以继续迁移他们的代码。 许可证，警告和调试模式将结束时间，被删除， - 非法访问选项本身。

When deny becomes the default mode then I expect permit to remain supported for at least one release, so that developers can continue to migrate their code. The permit, warn, and debug modes will, over time, be removed, as will the --illegal-access option itself.

所以它是更好地改变实施并遵循理想的解决方案。

So it's better to change the implementation and follow the ideal solution to it.

这篇关于JDK9：发生了非法反射访问操作。 org.python.core.PySystemState的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！