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

查看:31
本文介绍了JDK9:发生了非法的反射访问操作.org.python.core.PySystemState的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在尝试运行 DMelt 程序 (http://jwork.org/dmelt/) 程序使用 Java9 (JDK9),它给了我如下错误:

WARNING: 发生了非法的反射访问操作警告:org.python.core.PySystemState (file:/dmelt/jehep/lib/jython/jython.jar) 对方法 java.io.Console.encoding() 的非法反射访问警告:请考虑将此报告给 org.python.core.PySystemState 的维护者警告:使用 --illegal-access=warn 启用进一步非法反射访问操作的警告警告:在未来的版本中将拒绝所有非法访问操作

我该如何解决?我试图将 –illegal-access=permit 添加到脚本dmelt.sh"的最后一行(我在 Linux 中使用 bash),但这并没有解决这个问题.我对此感到非常沮丧.我经常使用这个程序,很长一段时间.也许我永远不应该迁移到 JDK9

解决方案

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

<块引用>

将此报告给 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 作为 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 的情况下,您可以简单地将其添加为 VM 选项 -

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


另外,请注意上面链接的同一线程

deny 成为默认模式时,我希望 permit 至少在一个版本中得到支持,以便开发人员可以继续迁移他们的代码.随着时间的推移,permitwarndebug 模式将被删除,--illegal-access 也将被删除代码>选项本身.

所以最好改变实现并遵循理想的解决方案.

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

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

reporting this to the maintainers of 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.

From one of the threads on the mailing list :

--illegal-access=permit

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.

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

This disables all illegal reflective-access operations except for those enabled by other command-line options, such as --add-opens. This will become the default mode in a future release.

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


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

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.

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

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

In your case to currently accessing 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

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

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆