Además de una comprensión de los accesos entre módulos y sus respectivos paquetes. Creo que el quid de esto radica en el Sistema de módulos # Relajado-fuerte-encapsulado y simplemente seleccionaría las partes relevantes para tratar de responder la pregunta.
¿Qué define un acceso reflectante ilegal y qué circunstancias desencadenan la advertencia?
Para ayudar en la migración a Java-9, se podría relajar la encapsulación sólida de los módulos.
Una implementación puede proporcionar acceso estático , es decir, mediante código de bytes compilado.
Puede proporcionar un medio para invocar su sistema de tiempo de ejecución con uno o más paquetes de uno o más de sus módulos abiertos para codificar en todos los módulos sin nombre , es decir, para codificar en el classpath. Si el sistema de tiempo de ejecución se invoca de esta manera, y si al hacerlo, algunas invocaciones de las API de reflexión tienen éxito donde de otro modo habrían fallado.
En tales casos, en realidad ha terminado haciendo un acceso reflectante que es "ilegal" ya que en un mundo modular puro no estaba destinado a hacer tales accesos.
¿Cómo encaja todo y qué desencadena la advertencia en qué escenario?
Esta relajación de la encapsulación se controla en tiempo de ejecución mediante una nueva opción --illegal-access
de iniciador que, por defecto, en Java9 es igual permit
. El permit
modo asegura
La primera operación de acceso reflectante a cualquier paquete de este tipo hace que se emita una advertencia, pero no se emiten advertencias después de ese punto. Esta única advertencia describe cómo habilitar más advertencias. Esta advertencia no se puede suprimir.
Los modos se pueden configurar con valores debug
(mensaje y seguimiento de pila para cada acceso), warn
(mensaje para cada acceso) y deny
(deshabilita tales operaciones).
Algunas cosas para depurar y corregir en aplicaciones serían: -
- Ejecútelo con
--illegal-access=deny
para conocer y evitar abrir paquetes de un módulo a otro sin una declaración de módulo que incluya dicha directiva ( opens
) o el uso explícito de --add-opens
VM arg.
- Las referencias estáticas del código compilado a las API internas de JDK se pueden identificar utilizando la
jdeps
herramienta con la --jdk-internals
opción
El mensaje de advertencia que se emite cuando se detecta una operación de acceso reflectante ilegal tiene la siguiente forma:
WARNING: Illegal reflective access by $PERPETRATOR to $VICTIM
dónde:
$PERPETRATOR
es el nombre completo del tipo que contiene el código que invocó la operación de reflexión en cuestión más la fuente del código (es decir, la ruta del archivo JAR), si está disponible, y
$VICTIM
es una cadena que describe el miembro al que se accede, incluido el nombre completo del tipo adjunto
Preguntas para este ejemplo de advertencia: = JDK9: Se ha producido una operación de acceso reflectante ilegal. org.python.core.PySystemState
Por último, y una nota importante, mientras trata de asegurarse de que no se enfrenta a tales advertencias y está a salvo en el futuro, todo lo que necesita hacer es asegurarse de que sus módulos no hagan esos accesos reflectantes ilegales. :)