问题
I having a strange issue with my selenium test
When I am opening my chrome browser im receiving 2 errors:
[1569419754.430][WARNING]: Timed out connecting to Chrome, retrying...
[1569419759.899][WARNING]: Timed out connecting to Chrome, retrying...
Before the browser actually opens. I also noticed at the end of the test there are numerous warnings:
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
I have tried updating the maven dependency:
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-java</artifactId>
<version>3.0.1</version>
</dependency>
But it then broke all my tests and i couldn't initialize the browser, anyone else have this issue?
回答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
来源：https://stackoverflow.com/questions/58100247/an-illegal-reflective-access-operation-has-occurred-while-executing-automated-te