In Java programming, the reflection API lets you examine the internal properties of a running Java program and manipulate them. The name of all its members can be displayed by a Java class, for example.
The "an illegal reflective access operation has occurred" warning message is related to the unauthorized access to parts of the JDK made by tools and libraries using reflection API.
In this article, we are going to show you what "an illegal reflective access operation has occurred" means and how to fix it.
What is "illegal reflective access"
From JDK9, an implementation may provide static access, i.e. by compiled bytecode or may provide a way 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.
In such cases, you’ve actually ended up making a reflective access which is "illegal" since in a pure modular world you were not meant to do such accesses.
In future releases of the JDK, this illegal access to reflective data will eventually be disabled. JDK 9, 10 and 11 permits it by default. Here is the warning message:
WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by com.tangosol.internal.util.ObjectFormatter (file:/opt/javaclasses/coherence/coherence.jar) to field java.lang.ref.Reference.referent WARNING: Please consider reporting this to the maintainers of com.tangosol.internal.util.ObjectFormatter 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
Permit illegal reflective access
Recent JDK versions still, by default, permits illegal access. Alternatively, in future releases, you can pass
--illegal-access=permit to the script and it would opens every package in every explicit module to code in all unnamed modules, i.e., code on the class path, just as
--permit-illegal-access does today.
The first illegal reflective-access operation causes a warning to be issued, as with
--permit-illegal-access, but no warnings are issued after that point. This single warning will describe how to enable further warnings.
Avoid illegal reflective access
The "an illegal reflective access operation has occurred" is merely a warning message and only indicating there is reflective access to JDK internal class without doing anything about it. In the meantime, you can either
- You can specify the reflective access explicitly using java’s –add-opens parameter. The migration guide for JDK 11 provides more information.
- Use a compatible and certified version of your software. If the software is actively maintained, then the developers are now aware of the warning and a fix may come in the near future.