Some tools and libraries use 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. In JDK 9, it is permitted by default and a warning is issued.

For example, here is the warning issued when starting Jython:

>java -jar jython-standalone-2.7.0.jar WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper (file:/C:/Jython/jython2.7.0/jython-standalone-2.7.0.jar) to method sun.nio.ch.SelChImpl.getFD() WARNING: Please consider reporting this to the maintainers of jnr.posix.JavaLibCHelper 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 Jython 2.7.0 (default:9987c746f838, Apr 29 2015, 02:25:11)

If you see a warning like this, contact the maintainers of the tool or library. The second line of the warning names the exact JAR file whose code used reflection to access an internal part of the JDK.

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 Jython in the following way:

>java --add-opens java.base/sun.nio.ch=ALL-UNNAMED --add-opens java.base/java.io=ALL-UNNAMED -jar jython-standalone-2.7.0.jar Jython 2.7.0 (default:9987c746f838, Apr 29 2015, 02:25:11)

This time, the warning is not issued because the java invocation explicitly acknowledges the reflective access. As you can see, you may need to specify multiple --add-opens flags to cover all of the reflective access operations that are attempted by libraries on the class path.

To better understand the behavior of tools and libraries, you can use the --illegal-access=warn command line flag. This flag causes a warning message to be issued for every illegal reflective-access operation. In addition, you can obtain detailed information about illegal reflective-access operations, including stack traces, by setting --illegal-access=debug .

If you have updated libraries, or when you get them, then you can experiment with using the --illegal-access=deny command line flag. It disables all reflective-access operations except for those enabled by other command-line options, such as --add-opens . This will be the default mode in a future release.

--illegal-access= deny , or, as already mentioned, to suppress warnings. If you need to use an internal API that has been made inaccessible, then use the --add-exports runtime option. You can also use --add-exports at compile time to access internal APIs.

runtime option. You can also use at compile time to access internal APIs. If you have to allow code on the class path to do deep reflection to access nonpublic members, then use the --add-opens option. There are two options that allow you to break encapsulation in specific ways. You could use these in combination with, or, as already mentioned, to suppress warnings.