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

Question

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

Answer 1

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 :

--illegal-access=permit

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.

--illegal-access=deny

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.