JDK9: An illegal reflective access operation has occurred. org.python.core.PySystemState
JavaJava 9Java ModuleJava 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 :
--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.
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:
<plugins>
. . .
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>3.2.2</version>
</plugin>
</plugins>
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:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.4</version>
...
...
</plugin>
To:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>3.3.1</version>
...
...
</plugin>
Change the artifactId and version From:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.5.1</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
TO:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>3.3.1</version>
<executions>
<execution>
<id>prepare-war</id>
<phase>prepare-package</phase>
<goals>
<goal>exploded</goal>
</goals>
</execution>
</executions>
</plugin>
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.