Java 什么是非法反射访问
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/50251798/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
what is an illegal reflective access
提问by Tschallacka
There are a lot of questions around about illegal reflective access in Java 9.
关于 Java 9 中的非法反射访问存在很多问题。
Now what I can't find because all Google spews up is people trying to work around the error messages, is what an illegal reflective access actually is.
现在我找不到，因为所有谷歌喷出来的都是试图解决错误消息的人，实际上是非法反射访问。
So my question fairly simple is:
所以我的问题很简单：
What defines an illegal reflective access and what circumstances trigger the warning?
什么定义了非法反射访问以及什么情况会触发警告？
I have gathered that it has something to do with the encapsulation principles that were introduced in Java 9, but how it all hangs together and what triggers the warning in what scenario I can't find an explanation to.
我收集到它与 Java 9 中引入的封装原则有关，但是它们如何结合在一起以及在我找不到解释的情况下触发警告的原因。
采纳答案by Naman
Apart from an understanding of the accesses amongst modules and their respective packages. I believe the crux of it lies in the Module System#Relaxed-strong-encapsulationand I would just cherry pick the relevant parts of it to try and answer the question.
除了了解模块及其各自包之间的访问之外。我相信它的症结在于模块系统#Relaxed-strong-encapsulation，我只想挑选它的相关部分来尝试回答这个问题。
What defines an illegal reflective access and what circumstances trigger the warning?
什么定义了非法反射访问以及什么情况会触发警告？
To aid in the migration to Java9, the strong encapsulation of the modules could be relaxed.
为了帮助迁移到 Java9，可以放松模块的强封装。
An implementation may provide static access, i.e. by compiled bytecode.
May provide a means to invoke its run-time system with one or more packages of one or more of its modules open to code in all unnamed modules, i.e. to code on the classpath. If the run-time system is invoked in this way, and if by doing so some invocations of the reflection APIs succeed where otherwise they would have failed.
一个实现可以提供静态访问，即通过编译的字节码。
可以提供一种方法来调用其运行时系统，其中一个或多个模块的一个或多个包对所有未命名模块中的代码开放，即在类路径上进行编码。如果以这种方式调用运行时系统，并且如果这样做，则反射 API 的某些调用会成功，否则它们将失败。
In such cases, you've actually ended up making a reflective accesswhich is "illegal"since in a pure modular world you were not meant to do such accesses.
在这种情况下，您实际上最终进行了“非法”的反射访问，因为在纯模块化世界中，您并不打算进行此类访问。
How it all hangs together and what triggers the warning in what scenario?
它是如何结合在一起的，什么情况下会触发警告？
This relaxation of the encapsulation is controlled at runtime by a new launcher option --illegal-accesswhich by default in Java9 equals permit. The permitmode ensures
这种封装的放松在运行时由一个新的启动器选项控制，--illegal-access在 Java9 中默认等于permit. 该permit模式确保
The first reflective-access operation to any such package causes a warning to be issued, but no warnings are issued after that point. This single warning describes how to enable further warnings. This warning cannot be suppressed.
对任何此类包的第一次反射访问操作会导致发出警告，但在那之后不会发出任何警告。此单个警告描述了如何启用更多警告。无法抑制此警告。
The modes are configurable with values debug(message as well as stacktrace for every such access), warn(message for each such access) and deny(disables such operations).
这些模式可以使用值debug（每个此类访问的消息以及堆栈跟踪）、warn（每个此类访问的消息）和deny（禁用此类操作）进行配置。
Few things to debug and fix on applications would be:-
调试和修复应用程序的几件事是：-
- Run it with
--illegal-access=denyto get to know about and avoid opening packages from one module to another without a module declaration including such a directive(opens) or an explicit use of--add-opensVM arg. Static references from compiled code to JDK-internal APIs could be identified using the
jdepstool with the--jdk-internalsoptionThe warning message issued when an illegal reflective-access operation is detected has the following form:
WARNING: Illegal reflective access by $PERPETRATOR to $VICTIMwhere:
$PERPETRATORis the fully-qualified name of the type containing the code that invoked the reflective operation in question plus the code source (i.e., JAR-file path), if available, and$VICTIMis a string that describes the member being accessed, including the fully-qualified name of the enclosing type
- 运行它
--illegal-access=deny以了解并避免在没有模块声明的情况下从一个模块打开包到另一个模块，包括这样的指令（opens）或显式使用--add-opensVM arg。 可以使用
jdeps带有--jdk-internals选项的工具识别从编译代码到 JDK 内部 API 的静态引用检测到非法反射访问操作时发出的警告消息具有以下形式：
WARNING: Illegal reflective access by $PERPETRATOR to $VICTIM在哪里：
$PERPETRATOR是包含调用相关反射操作的代码的类型的完全限定名称以及代码源（即 JAR 文件路径）（如果可用），以及$VICTIM是描述正在访问的成员的字符串，包括封闭类型的完全限定名称
Questions for such a sample warning: = JDK9: An illegal reflective access operation has occurred. org.python.core.PySystemState
此类示例警告的问题： = JDK9：发生了非法反射访问操作。org.python.core.PySystemState
Last and an important note, while trying to ensure that you do not face such warnings and are future safe, all you need to do is ensure your modules are not making those illegal reflective accesses. :)
最后一个重要的注意事项，在努力确保您不会面临此类警告并且将来是安全的时，您需要做的就是确保您的模块不会进行那些非法的反射访问。:)
回答by ptomli
There is an Oracle articleI found regarding Java 9 module system
我发现了一篇关于 Java 9 模块系统的 Oracle文章
By default, a type in a module is not accessible to other modules unless it's a public type and you export its package. You expose only the packages you want to expose. With Java 9, this also applies to reflection.
默认情况下，模块中的类型不能被其他模块访问，除非它是公共类型并且您导出它的包。您只公开要公开的包。对于 Java 9，这也适用于反射。
As pointed out in https://stackoverflow.com/a/50251958/134894, the differences between the AccessibleObject#setAccessiblefor JDK8 and JDK9 are instructive. Specifically, JDK9 added
正如https://stackoverflow.com/a/50251958/134894 中所指出的AccessibleObject#setAccessible，JDK8 和 JDK9之间的差异具有指导意义。具体来说，JDK9添加了
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.
如果以下任何一项成立，则类 C 中的调用者可以使用此方法来启用对声明类 D 的成员的访问：
- C 和 D 在同一个模块中。
- 在包含 D 的模块导出到至少包含 C 的模块的包中，成员是公共的，D 是公共的。
- 该成员是 protected static，D 在包含 D 的模块导出到至少包含 C 的模块的包中是公共的，并且 C 是 D 的子类。
- D 位于包含 D 的模块至少对包含 C 的模块开放的包中。未命名和开放模块中的所有包对所有模块开放，因此当 D 位于未命名或开放模块中时，此方法总是成功。
which highlights the significance of modules and their exports (in Java 9)
它突出了模块及其导出的重要性（在 Java 9 中）
回答by user158037
Just look at setAccessible()method used to access privatefields and methods:
只需查看setAccessible()用于访问private字段和方法的方法：
Now there is a lot more conditions required for this method to work. The only reason it doesn't break almost all of older software is that modules autogenerated from plain JARs are very permissive (open and export everything for everyone).
现在，此方法需要更多条件才能起作用。它不会破坏几乎所有旧软件的唯一原因是从普通 JAR 自动生成的模块非常宽松（为每个人打开并导出所有内容）。
