En este artículo, JDK 9: Propuesta para permitir el acceso ilegal reflectante de forma predeterminada , las afirmaciones de que la –permit-illegal-accessopción será reemplazado por una opción más general, –illegal-access.
–illegal-access=permit–illegal-access=warn–illegal-access=debug–illegal-access=deny
➥ sucedió eso? ¿Hay un –illegal-accessajuste?
➥ ¿Cómo son estas set? Argumentos a lanzar la JVM?
➥ ¿Cómo se puede obtener el valor actual durante el tiempo de ejecución?
Pasó eso? ¿Hay un ajuste de acceso -ilegal?
Sí, parece que fue así, al menos por OpenJDK / OracleJDK. La opción aparece en la documentación de la java"herramienta".
También aparece cuando se ejecuta java --help-extra.
Nota: La documentación del JDK-11 menciona esta opción se quitará en una versión futura.
¿Cómo son estas set? Argumentos a lanzar la JVM?
Sí, es una opción de línea de comandos. Ejemplo:
java --illegal-access=deny --module-path <path> --module <module>/<main-class> [args...]
¿Cómo se puede obtener el valor actual durante el tiempo de ejecución?
Por desgracia, no estoy al tanto de cualquier forma de consultar el valor en tiempo de ejecución. No parece ser parte de las propiedades del sistema o el medio ambiente. He intentado encontrar el que se utilizó el valor internamente, pero no pudo (pero para ser honesto yo no pasar demasiado tiempo mirando).
Para mayor comodidad, aquí está la documentación de --illegal-accessJDK-11:
--illegal de acceso = parámetro
Cuando está presente en tiempo de ejecución,
--illegal-access=toma una palabra claveparameterpara especificar un modo de funcionamiento:Nota:
Esta opción se quitará en una versión futura.
permit: Este modo se abre cada paquete en cada módulo de la imagen en tiempo de ejecución para código en todos los módulos sin nombre (como el código en la ruta de clase), si existiera ese paquete en el JDK 8. Esto permite tanto el acceso estático, (por ejemplo, bytecode compilado, y el acceso profundo de reflexión) a través de varias API de reflexión de la plataforma. La primera operación de acceso reflexivo a cualquier paquete provoca una advertencia a ser emitida. Sin embargo, no hay advertencias son emitidas después de la primera ocurrencia. Esto solo aviso describe cómo habilitar otras advertencias. Este modo es el valor predeterminado para el JDK actual, pero va a cambiar en una versión futura.
warn: Este modo es idéntica apermitexcepción de que un mensaje de aviso se emite para cada operación reflectante de acceso ilegal.
debug: Este modo es idéntica awarnexcepción de que tanto un mensaje de advertencia y un seguimiento de pila se emiten para cada operación de acceso reflectante ilegal.
deny: Este modo desactiva todas las operaciones de acceso ilegal a excepción de los habilitados por otras opciones de línea de comandos, como--add-opens. Este modo se convertirá en el predeterminado en una versión futura.El modo por defecto,
--illegal-access=permitse pretende hacerle consciente de código en la ruta de clase que reflexivamente accede a cualquier API de JDK-internos al menos una vez. Para obtener información sobre todos estos accesos, se puede utilizar elwarno losdebugmodos. Para cada biblioteca o marco sobre la ruta de clase que requiere el acceso ilegal, tiene dos opciones:
Si mantenedores del componente ya han lanzado una versión fija que no hay usos más largos JDK-internos API entonces se puede considerar la actualización a la versión.
Si el componente todavía tiene que ser fijo, a continuación, puede ponerse en contacto con sus mantenedores y pedirles que reemplazar el uso de las API de JDK-internas con las API exportadas adecuados.
Si no puede dejar de utilizar un componente que requiere el acceso ilegal, a continuación, puede eliminar los mensajes de advertencia mediante el uso de una o más
--add-opensopciones para abrir sólo aquellos paquetes internos a los que se requiere el acceso.Para verificar que su aplicación está lista para una futura versión del JDK, ejecutarlo con
--illegal-access=denyjunto con las necesarias--add-opensopciones. Cualquier resto de errores de acceso ilegal serán muy probablemente debido a las referencias estáticas de código compilado a las API de JDK-internos. Puede identificar a los ejecutando el jdeps herramienta con la--jdk-internalsopción. Por motivos de rendimiento, el JDK actual no emite advertencias para las operaciones de acceso estática ilegales.