JDK9: An illegal reflective access operation has occurred. org.python.core.PySystemState

JavaJava 9Java Module

Java Problem Overview

I'm trying to run DMelt programs (http://jwork.org/dmelt/) program using Java9 (JDK9), and it gives me errors such as:

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.python.core.PySystemState (file:/dmelt/jehep/lib/jython/jython.jar) to method java.io.Console.encoding()
WARNING: Please consider reporting this to the maintainers of org.python.core.PySystemState
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

How can I fix it? I was trying to add –illegal-access=permit to the last line of the script "dmelt.sh" (I'm using bash in Linux), but this did not solve this problem. I'm very frustrating with this. I was using this program very often, for very long time. Maybe I should never move to JDK9

Java Solutions

Solution 1 - Java

The ideal way to resolve this would be to

> reporting this to the maintainers of org.python.core.PySystemState

and asking them to fix such reflective access going forward.

> If the default mode permits illegal reflective access, however, then > it's essential to make that known so that people aren't surprised when > this is no longer the default mode in a future release.

From one of the threads on the mailing list :


> This will be the default mode for JDK 9. It 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.


> This disables all illegal reflective-access operations except for > those enabled by other command-line options, such as --add-opens. > This will become the default mode in a future release.

Warning messages in any mode can be avoided, as before, by the judicious use of the --add-exports and --add-opens options.

Hence a current temporary solution available is to use --add-exports as the VM arguments as mentioned in the docs :

--add-exports module/package=target-module(,target-module)*

> Updates module to export package to target-module, regardless of > module declaration. The target-module can be all unnamed to export to > all unnamed modules.

This would allow the target-module to access all public types in package. In case you want to access the JDK internal classes which would still be encapsulated, you would have to allow a deep reflection using the --add-opens argument as:

--add-opens module/package=target-module(,target-module)*

> Updates module to open package to target-module, regardless of module > declaration.

In your case to currently accessing the java.io.Console, you can simply add this as a VM option -

--add-opens java.base/java.io=ALL-UNNAMED

Also, note from the same thread as linked above

When deny becomes the default mode then I expect permit to remain supported for at least one release so that developers can continue to migrate their code. The permit, warn, and debug modes will, over time, be removed, as will the --illegal-access option itself.

So it's better to change the implementation and follow the ideal solution to it.

Solution 2 - Java

DMelt seems to use Jython and this warning is something that the Jython maintainers will need to address. There is an issue tracking it here: http://bugs.jython.org/issue2582

Solution 3 - Java

Real issue is a problem in the JDK. There is actually no illegal access, but the JDK method trySetAccessible is misbehaving. This will hopefully be fixed in a future JDK version.

try solve below answer link

Solution 4 - Java

To avoid this error, you need to redefine maven-war-plugin to a newer one. For example:

    . . .

Works for jdk-12.

Solution 5 - Java

Jython developers do not have any practical solution for jdk9, according to this post http://bugs.jython.org/issue2582. The previous explanation seems very long to figure out what should done. I just want jdk9 behaves exactly as jdk1.4 - 1.8, i.e be totally silent. The JVM strength in backward comparability. I'm totally OK to have additional options in JDK9, but new features cannot break applications

Solution 6 - Java

Since the Java update 9, the "illegal reflective access operation has occurred" warning occurs.

To remove the warning message. You can replace maven-compiler-plugin with maven-war-plugin and/or updating the maven-war-plugin with the latest version in your pom.xml. Following are 2 examples:

Change version from:




Change the artifactId and version From:




When i re-run Maven Build or Maven Install, the "illegal reflective access operation has occurred" is gone.

Solution 7 - Java

Perhaps the fix below works for java 9 as well:

In my case the java open jdk version was 10.0.2 and got the same error (An illegal reflective access opeeration has occurred). I upgraded maven to version 3.6.0 on linux, and the problem was gone.

Solution 8 - Java

Came here while working on a Kotlin Spring project. Resolved the issue by:

cd /project/root/
touch .mvn/jvm.config
echo "--illegal-access=permit" >> .mvn/jvm.config

Solution 9 - Java

Some recent feedback.

as stated in the java error code

WARNING: All illegal access operations will be denied in a future release

This future release is JDK 17, where the launcher parameter --illegal-access will stop working.

More information direct from Oracle can be found here: JEP 403 link 1 and JEP 403 link 2

> With this change, it will no longer be possible for end users to use > the --illegal-access option to enable access to internal elements of > the JDK. (A list of the packages affected is available here.) The > sun.misc and sun.reflect packages will still be exported by the > jdk.unsupported module, and will still be open so that code can access > their non-public elements via reflection. No other JDK packages will > be open in this way. > > It will still be possible to use the data-shared-secret="1631525318374-0.6975299137577347">--add-opens > command-line option, or the data-shared-secret="1631525318374-0.6975299137577347">Add-Opens > JAR-file manifest attribute, to open specific packages.

So the solution --add-opens module/package=target-module(,target-module)* and the example --add-opens java.base/java.io=ALL-UNNAMED will keep working for JDK 17 and future releases but the --illegal-access will not.


All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionIraSView Question on Stackoverflow
Solution 1 - JavaNamanView Answer on Stackoverflow
Solution 2 - JavaAlan BatemanView Answer on Stackoverflow
Solution 3 - JavaThilina SampathView Answer on Stackoverflow
Solution 4 - Javauser8280225View Answer on Stackoverflow
Solution 5 - JavaIraSView Answer on Stackoverflow
Solution 6 - JavaQA SpecialistView Answer on Stackoverflow
Solution 7 - JavaRob LasscheView Answer on Stackoverflow
Solution 8 - JavaAndroidView Answer on Stackoverflow
Solution 9 - JavaPanagiotis BougioukosView Answer on Stackoverflow