JDK9:发生了非法的反射访问操作.org.python.core.PySystemState [英] JDK9: An illegal reflective access operation has occurred. 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
至少在一个版本中得到支持,以便开发人员可以继续迁移他们的代码.随着时间的推移,permit
、warn
和 debug
模式将被删除,--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 totarget-module
, regardless of module declaration. Thetarget-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 totarget-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屋!