This article, JDK 9: Proposal to allow illegal reflective access by default, claims that the –permit-illegal-access
option will be replaced by a more general option, –illegal-access
.
–illegal-access=permit
–illegal-access=warn
–illegal-access=debug
–illegal-access=deny
➥ Did that happen? Is there a –illegal-access
setting?
➥ How are these set? Arguments to launching the JVM?
➥ How does one get the current value during runtime?
The default mode, --illegal-access=permit , is intended to make you aware of code on the class path that reflectively accesses any JDK-internal APIs at least once. To learn about all such accesses, you can use the warn or the debug modes.
To verify that your application is ready for a future version of the JDK, run it with --illegal-access=deny along with any necessary --add-opens options. Any remaining illegal-access errors will most likely be due to static references from compiled code to JDK-internal APIs.
1) it is --illegal-access=deny (note the two dashes), 2) you should use value permit , not deny (deny disallows it entirely), and 3) you should set it on the run configuration of your application, not in the run configuration of IntelliJ itself.
Yes, it appears that did happen—at least for OpenJDK/OracleJDK. The option is listed in the documentation for the java
"tool".
It is also listed when executing java --help-extra
.
Note: The JDK-11 documentation mentions this option will be removed in a future release.
Yes, it is a command-line option. Example:
java --illegal-access=deny --module-path <path> --module <module>/<main-class> [args...]
Unfortunately, I'm not aware of any way to query the value at runtime. It doesn't appear to be part of the system or environment properties. I tried finding where the value was used internally but was unable to (but to be honest I didn't spend too much time looking).
For convenience, here's the documentation of --illegal-access
for JDK-11:
--illegal-access=parameter
When present at run time,
--illegal-access=
takes a keywordparameter
to specify a mode of operation:Note:
This option will be removed in a future release.
permit
: This mode opens each package in each module in the run-time image to code in all unnamed modules ( such as code on the class path), if that package existed in JDK 8. This enables both static access, (for example, by compiled bytecode, and deep reflective access) through the platform's various reflection APIs. The first reflective-access operation to any such package causes a warning to be issued. However, no warnings are issued after the first occurrence. This single warning describes how to enable further warnings. This mode is the default for the current JDK but will change in a future release.
warn
: This mode is identical topermit
except that a warning message is issued for each illegal reflective-access operation.
debug
: This mode is identical towarn
except that both a warning message and a stack trace are issued for each illegal reflective-access operation.
deny
: This mode disables all illegal-access operations except for those enabled by other command-line options, such as--add-opens
. This mode will become the default in a future release.The default mode,
--illegal-access=permit
, is intended to make you aware of code on the class path that reflectively accesses any JDK-internal APIs at least once. To learn about all such accesses, you can use thewarn
or thedebug
modes. For each library or framework on the class path that requires illegal access, you have two options:
If the component's maintainers have already released a fixed version that no longer uses JDK-internal APIs then you can consider upgrading to that version.
If the component still needs to be fixed, then you can contact its maintainers and ask them to replace their use of JDK-internal APIs with the proper exported APIs.
If you must continue to use a component that requires illegal access, then you can eliminate the warning messages by using one or more
--add-opens
options to open only those internal packages to which access is required.To verify that your application is ready for a future version of the JDK, run it with
--illegal-access=deny
along with any necessary--add-opens
options. Any remaining illegal-access errors will most likely be due to static references from compiled code to JDK-internal APIs. You can identify those by running the jdeps tool with the--jdk-internals
option. For performance reasons, the current JDK does not issue warnings for illegal static-access operations.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With