使用 Selenium 和 Java 9 执行自动化测试时发生非法反射访问操作

Question

我的硒测试有一个奇怪的问题

当我打开我的 chrome 浏览器时，我收到 2 个错误：

[1569419754.430][WARNING]: Timed out connecting to Chrome, retrying...
[1569419759.899][WARNING]: Timed out connecting to Chrome, retrying...

在浏览器实际打开之前。我还注意到在测试结束时有很多警告：

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.openqa.selenium.os.ProcessUtils 
WARNING: Please consider reporting this to the maintainers of org.openqa.selenium.os.ProcessUtils
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

我尝试更新 maven 依赖项：

<dependency>
    <groupId>org.seleniumhq.selenium</groupId>
    <artifactId>selenium-java</artifactId>
    <version>3.0.1</version>
</dependency>

但是它破坏了我所有的测试，我无法初始化浏览器，还有其他人有这个问题吗？

Answer 1

Selenium's Java client tools and libraries uses reflection to access parts of the JDK that are meant for internal use only. This illegal reflective access will be disabled in a future release of the JDK. While using JDK 9, it is permitted by default and a warning is issued as follows:

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.openqa.selenium.os.ProcessUtils 
WARNING: Please consider reporting this to the maintainers of org.openqa.selenium.os.ProcessUtils
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

As per the article Understanding Runtime Access Warnings by default, a maximum of one warning about reflective access is issued in the lifetime of the process started by the java launcher. The exact timing of the warning depends on the behavior of tools and libraries performing reflective–access operations. The warning may appear early in the lifetime of the process, or a long time after startup.

You can disable the warning message on a library-by-library basis by using the --add-opens command line flag. For example, you can start Selenium in the following way:

>java --add-opens java.base/sun.nio.ch=ALL-UNNAMED --add-opens java.base/java.io=ALL-UNNAMED -jar selenium-server-standalone-3.14.0.jar

Relaxing strong encapsulation

To help us in the migration to Java 9, an implementation was needed to relax the strong encapsulation of the modules that that would have addressed the following:

• An implementation which may provide some 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 class path. 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, then the first such invocation must cause a warning to be issued on the standard error stream. Later such invocations may also cause warnings to be issued.

• An implementation which may by default, open one or more packages of one or more of its modules to code in all unnamed modules at run time. If it does so then it must issue warnings as described in the previous paragraph. If it does so then it must, further, provide a means to invoke its run-time system without opening any packages of any of its modules. (The Reference Implementation’s run-time system behaves this way by default, and because this is the default it can also be invoked without opening any of its packages via the command-line option --illegal-access=deny.)

Future revisions of this specification are expected to mandate that all of an implementation’s modules be strongly encapsulated by default and, eventually, to disallow the above-described relaxation.

JEP 261: Module System

With the arrival of JEP 261: Module System the strong encapsulation of some of the JDK's packages is relaxed by default, as permitted by the Java SE 9 Platform Specification. This relaxation is controlled at run time by a new launcher option --illegal-access, which works as follows:

• --illegal-access=permit: This option opens each package in each module in the run-time image to code in all unnamed modules, i.e., to code on the class path, if that package existed in JDK 8. This enables both static access, i.e., by compiled bytecode, and deep reflective access, via the platform's various reflection APIs.
• --illegal-access=warn: This option is identical to permit except that a warning message is issued for each illegal reflective-access operation.
• --illegal-access=debug: This option is identical to warn except both a warning message and a stack trace are issued for each illegal reflective-access operation.
• --illegal-access=deny: This option disables all illegal-access operations except for those enabled by other command-line options, e.g., --add-opens.

Note: This mode is the default in JDK 9. It will be phased out in a future release and, eventually, removed.

Solution

A quick fix solution would be to revert back to the latest version of Java 8