There are a lot of questions around about illegal reflective access in 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.
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-encapsulation and I would just cherry pick the relevant parts of it to try and answer the question.
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.
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.
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.
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-access which by default in Java9 equals permit. The permit mode ensures
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).
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
Questions for such a sample warning: = JDK9: An illegal reflective access operation has occurred. 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. :)