java - modules - JDK9: se ha producido una operación ilegal de acceso reflectante. org.python.core.PySystemState

java modular

Question

Estoy tratando de ejecutar programas DMelt ( http://jwork.org/dmelt/ ) utilizando Java9 (JDK9), y me da errores como:

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

¿Cómo puedo arreglarlo? Intenté agregar –illegal-access = permit a la última línea del script "dmelt.sh" (estoy usando bash en Linux), pero esto no resolvió este problema. Estoy muy frustrante con esto. Estaba usando este programa muy a menudo, durante mucho tiempo. Tal vez nunca debería mudarme a JDK9

Answer 1

El problema real es un problema en el JDK. En realidad no hay acceso ilegal, pero el método JDK trySetAccessible se está portando mal. Con suerte, esto se solucionará en una futura versión de JDK.

intenta resolver el siguiente link respuesta

Answer 2

La forma ideal de resolver esto sería

informar esto a los mantenedores de org.python.core.PySystemState

y pidiéndoles que arreglen ese acceso reflexivo en el futuro.

Sin embargo, si el modo predeterminado permite el acceso reflectante ilegal, entonces es esencial darlo a conocer para que las personas no se sorprendan cuando este ya no sea el modo predeterminado en una versión futura.

De uno de los hilos en la lista de correo :

--illegal-access=permit

Este será el modo predeterminado para JDK 9. Abre todos los paquetes en cada módulo explícito para codificar en todos los módulos sin nombre, es decir, el código en la ruta de clase, tal como lo hace hoy --permit-illegal-access .

La primera operación ilegal de acceso reflexivo hace que se emita una advertencia, como con --permit-illegal-access , pero no se emiten advertencias después de ese punto. Esta advertencia única describirá cómo habilitar advertencias adicionales.

--illegal-access=deny

Esto deshabilita todas las operaciones ilegales de acceso reflexivo, excepto las habilitadas por otras opciones de línea de comandos, como --add-opens . Este se convertirá en el modo predeterminado en una versión futura.

Los mensajes de advertencia en cualquier modo se pueden evitar, como antes, mediante el uso juicioso de las --add-exports y --add-opens .

Por lo tanto, una solución temporal actual disponible es usar --add-exports como los argumentos de VM como se menciona en los docs :

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

Actualiza el módulo para export paquete al target-module , independientemente de la declaración del módulo. El target-module puede estar sin nombre para exportar a todos los módulos sin nombre.

Esto permitiría que el target-module acceda a todos los tipos públicos en el package . En caso de que desee acceder a las clases internas de jdk que aún estarían encapsuladas, tendría que permitir una reflexión profunda utilizando el argumento --add-opens como:

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

Actualiza el módulo para open paquete al target-module , independientemente de la declaración del módulo.

En su caso para acceder actualmente a java.io.Console , simplemente puede agregar esto como una opción de VM:

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

Además, tenga en cuenta el mismo hilo que el enlace anterior

Cuando deny convierte en el modo predeterminado, espero que el permit siga siendo compatible durante al menos una versión, para que los desarrolladores puedan continuar migrando su código. Los modos de permit , warn y debug se eliminarán, con el tiempo, al igual que la --illegal-access .

Por lo tanto, es mejor cambiar la implementación y seguir la solución ideal.

Answer 3

Los desarrolladores de Jython no tienen ninguna solución práctica para jdk9, según esta publicación http://bugs.jython.org/issue2582 . La explicación anterior parece muy larga para descubrir qué debería hacerse. Solo quiero que jdk9 se comporte exactamente como jdk1.4 - 1.8, es decir, sea totalmente silencioso. La fuerza de JVM en la comparabilidad hacia atrás. Estoy totalmente de acuerdo con tener opciones adicionales en JDK9, pero las nuevas características no pueden romper las aplicaciones

Answer 4

Para evitar este error, debe redefinir el maven-war-plugin a uno más nuevo. Por ejemplo:

<plugins>
. . .
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>3.2.2</version>
</plugin>
</plugins>

PS funciona para jdk-12

Answer 5

Parece que DMelt usa Jython y esta advertencia es algo que los encargados del mantenimiento de Jython deberán abordar. Hay un problema para rastrearlo aquí: http://bugs.jython.org/issue2582

Answer 6

Quizás la solución a continuación funcione también para Java 9:

En mi caso, la versión java open jdk era 10.0.2 y obtuvo el mismo error (se ha producido una operación de acceso reflectante ilegal). Actualicé Maven a la versión 3.6.0 en Linux, y el problema desapareció.