如何解决Java“非法访问操作”方法将被弃用吗?
如果您使用诸如setAccessible()
之类的非法访问,则JDK 9+ JVM发出非法访问操作警告之后。
我的问题
-
setAccessible()
将来会被屏蔽吗? - 此功能的官方参考文件在哪里(如果不推荐使用)?
在任何地方都找不到参考,谢谢。
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.hazelcast.internal.networking.nio.SelectorOptimizer (file:/var/folders/9w/wp9vfqmn2ql0mp3lgym0bxf40000gn/T/toy.war-spring-boot-libs-0024b388-730f-430b-b21b-1611bd2ad612/hazelcast-4.0.2.jar) to field sun.nio.ch.SelectorImpl.selectedKeys
WARNING: Please consider reporting this to the maintainers of com.hazelcast.internal.networking.nio.SelectorOptimizer
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
解决方法
1。 setAccessible()
将来会被屏蔽吗?
不,AccessibleObject#setAccessible(boolean)
不被弃用,据我所知,也没有计划弃用它。
您看到的警告与此方法有关,但不直接相关。 Java 9中引入的 Java平台模块系统在编译时和运行时(即反射)都添加了更强大的封装。 #setAccessible(boolean)
记录了运行时规则:
如果满足以下任一条件,则类
C
中的调用方可以使用此方法来访问声明类D
的成员:
C
和D
在同一模块中。- 在包含
D
的模块至少导出到包含D
的模块的包中,成员是公共的,而C
是公共的。- 成员是静态受保护的,
D
在包含以下内容的包中是公共的:包含D
的模块至少导出到包含C
的模块,并且C
是子类的D
。D
在一个包中,至少包含D
的模块可以打开包含C
的模块。未命名和打开的模块中的所有软件包都对所有模块开放,因此,当D
在未命名或打开的模块中时,此方法总是成功。当声明类位于与调用者不同的模块中并且包含声明类的包为无法打开呼叫者的模块。
与Java 8相比,这是一个重大变化,当反射可以自由控制想要的任何内容时(假设没有SecurityManager
)。突破性的变化是一个问题,因为Java以向后兼容而自豪。为了为库和框架提供足够的时间来迁移,他们放松了针对特定情况的强大封装(请参见下文)。
2。此功能的官方参考在哪里(将来将不推荐使用)?
您看到的警告与java
tool specification记录的--illegal-access
选项有关:
在运行时出现时,
--illegal-access=
使用关键字 parameter 指定操作模式:注意:此选项将在以后的版本中删除。
permit
:此模式打开运行时映像中每个模块中的每个程序包,以对所有未命名模块(例如,类路径中的代码)进行编码(如果该程序包存在于JDK 8 [已添加重点] 。这样就可以通过平台的各种反射API进行静态访问(例如,通过编译的字节码进行访问)和深度反射访问。对任何此类包装的第一次反射式访问操作都会发出警告。但是,第一次出现后不会发出警告。此单个警告描述了如何启用进一步的警告。 此模式是当前JDK的默认模式,但在以后的版本中会更改。 [添加了重点] 。
warn
:此模式与允许相同,不同之处在于,每次非法反射访问操作都会发出警告消息。
debug
:除了为每个非法的反射访问操作同时发出警告消息和堆栈跟踪信息外,此模式与警告相同。
deny
:此模式将禁用所有非法访问操作,但其他命令行选项(例如--add-opens
启用的操作除外)。 此模式将在将来的版本中成为默认模式。 [添加了重点] 。默认模式
--illegal-access=permit
旨在使您了解类路径上的代码,这些代码至少可以一次反射地访问任何JDK内部API。要了解所有此类访问,可以使用警告或调试模式。对于类路径上需要非法访问的每个库或框架,您有两个选择:
如果组件的维护者已经发布了不再使用JDK内部API的固定版本,则可以考虑升级到该版本。
如果仍然需要修复该组件,则可以联系其维护者,并要求他们使用适当的导出API替换其对JDK内部API的使用。
如果必须继续使用需要非法访问的组件,则可以通过使用一个或多个
--add-opens
选项仅打开那些需要访问权限的内部软件包来消除警告消息。要验证您的应用程序已准备好用于将来的JDK版本,请使用
--illegal-access=deny
以及任何必要的--add-opens
选项运行它。任何剩余的非法访问错误很可能归因于从编译代码到JDK内部API的静态引用。您可以通过使用jdeps
选项运行--jdk-internals
工具来识别它们。出于性能原因,当前的JDK不会针对非法的静态访问操作发出警告。
总结重点部分:
- 默认模式为
permit
。- 这允许未命名模块中的代码(即类路径)访问运行时映像(即JDK)中模块内的成员,即使这些成员未导出/未打开的软件包(只要这些软件包存在于JDK 8中)。
- 最终,默认模式将为
deny
。- 这时任何尚未正确迁移的代码都将停止工作。这就是为什么看到警告的原因-他们希望您解决问题(如果是您的代码,则是您自己;如果是第三方代码,则是通过提交错误报告)。
-
--illegal-access
选项本身最终将被完全删除。
这些更改将在什么版本中发生...我不知道。但是,--illegal-access
选项可能会在默认模式变为deny
后一两个版本中被删除。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。