Java `illegal access operations` 方法将被弃用？

Question

这个问题在这里已经有了答案:





What is an illegal reflective access?

(5 个回答)


去年关闭。




在 JDK 9+ JVM 之后，如果您使用了一些非法访问，例如 setAccessible()，则会发出非法访问操作警告。 .
我的问题

是 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

Answer 1

1.是setAccessible()以后会被屏蔽吗？
不， AccessibleObject#setAccessible(boolean) 没有被弃用，据我所知，也没有计划弃用它。
您看到的警告与此方法相关，但不直接相关。 Java 9 中引入的 Java 平台模块系统在编译时和运行时(即反射)都增加了更强的封装。运行时规则由 #setAccessible(boolean) 记录。 :

This method may be used by a caller in class C to enable access to a member of declaring class D if any of the following hold:

• C and D are in the same module.
• The member is public and D is public in a package that the module containing D exports to at least the module containing C.
• The member is protected static, D is public in a package that the module containing D exports to at least the module containing C, and C is a subclass of D.
• D is in a package that the module containing D opens to at least the module containing C. All packages in unnamed and open modules are open to all modules and so this method always succeeds when D is in an unnamed or open module.

This method cannot be used to enable access to private members, members with default (package) access, protected instance members, or protected constructors when the declaring class is in a different module to the caller and the package containing the declaring class is not open to the caller's module.

这是 Java 8 的一个重大变化，当时反射可以自由地访问它想要的任何东西(假设没有 SecurityManager)。重大更改是一个问题，因为 Java 以向后兼容性为荣。为了给库和框架提供足够的迁移时间，他们针对特定场景放宽了这种强封装(见下文)。

2. 此功能的官方引用(将来会弃用)在哪里？
您看到的警告与 --illegal-access 有关选项，由 java tool specification 记录:

When present at run time, --illegal-access= takes a keyword parameter to specify a mode of operation:

Note: This option will be removed in a future release.

permit :此模式打开运行时镜像中每个模块中的每个包，以在所有未命名模块(例如类路径上的代码)中编码，如果该包存在于 JDK 8 [强调]。这允许通过平台的各种反射 API 进行静态访问(例如，通过编译的字节码和深度反射访问)。对任何此类包的第一次反射访问操作会导致发出警告。但是，在第一次发生后不会发出警告。此单个警告描述了如何启用更多警告。 此模式是当前 JDK 的默认模式，但将在 future 版本中更改 [强调]。

warn : 此模式与 permit 相同，只是为每个非法反射访问操作发出警告消息。

debug : 此模式与警告相同，除了为每个非法反射访问操作发出警告消息和堆栈跟踪之外。

deny : 此模式禁用所有非法访问操作，但由其他命令行选项启用的操作除外，例如 --add-opens . 此模式将成为 future 版本中的默认模式 [强调]。

默认模式， --illegal-access=permit , 旨在让您了解类路径上的代码至少反射访问任何 JDK 内部 API 一次。要了解所有此类访问，您可以使用警告或 Debug模式。对于需要非法访问的类路径上的每个库或框架，您有两个选择:

如果组件的维护者已经发布了不再使用 JDK 内部 API 的固定版本，那么您可以考虑升级到该版本。

如果该组件仍然需要修复，那么您可以联系其维护人员，并要求他们使用适当的导出 API 替换对 JDK 内部 API 的使用。

如果您必须继续使用需要非法访问的组件，那么您可以使用一个或多个 --add-opens 来消除警告消息。选项以仅打开需要访问的那些内部包。
要验证您的应用程序是否已为 JDK 的 future 版本做好准备，请使用 --illegal-access=deny 运行它。以及任何必要的 --add-opens选项。任何剩余的非法访问错误很可能是由于从编译代码到 JDK 内部 API 的静态引用。您可以通过运行 jdeps 来识别这些。带有 --jdk-internals 的工具选项。出于性能原因，当前的 JDK 不会对非法静态访问操作发出警告。

总结强调的部分:

默认模式是 permit .

这允许未命名模块(即类路径)中的代码访问运行时镜像(即 JDK)中模块内的成员，即使这些成员位于未导出/未打开的包中(只要这些包存在于 JDK 8 中)。

最终默认模式将是 deny .

此时任何未正确迁移的代码都将停止工作。这就是您看到警告的原因——他们希望您解决问题(如果是您自己的代码，或者提交错误报告，如果是第三方代码)。

--illegal-access选项本身最终将被完全删除。

这些变化将在什么版本中发生......我不知道。然而， --illegal-access在默认模式变为 deny 后，选项可能会被删除一两个版本。 .
更新(2021 年 5 月 31 日)
JEP 396: Strongly Encapsulate JDK Internals by Default随 Java 16 一起提供并设为默认模式 deny . --illegal-access选项仍然存在。
JEP 403: Strongly Encapsulate JDK Internals当前针对 Java 17。这将使 permit , warn , 和 debug模式无效并尝试使用它们将导致发出警告。然而， --illegal-access选项将暂时保留(但计划在 future 版本中删除)。