java - Alternativa a sun.misc.Signal

signals compatibility

Question

Comencé a investigar para encontrar una alternativa a la clase sun.misc.Signal , ya que podría no tener soporte en los próximos JDK (actualmente estamos trabajando en 1.6). Cuando construyo el proyecto obtengo:

advertencia: sun.misc.SignalHandler es una API propiedad de Sun y puede eliminarse en una versión futura

Encontré múltiples soluciones pero no encajan en mi proyecto, por ejemplo, en esta pregunta .

Esto es inaceptable en mi situación porque:

• Las señales se utilizan no solo para matar la aplicación.
• La aplicación es enorme: cada cambio conceptual de comunicación entre módulos / JVM podría tardar años en implementarse

Por lo tanto, la solución deseable es encontrar algo como una nueva versión de Oracle de esta clase o algo que funcione de la misma manera. ¿Existe tal solución?

Answer 1

Como encontrará infinito ad repetido cuando aprenda sobre el manejo de señales en Java, le recomendamos que evite escribir código Java que dependa directamente de las señales. La mejor práctica general es permitir que la JVM salga normalmente en ctrl + c y otras señales al registrar un gancho de apagado en su lugar. El manejo de señales directamente hace que su programa Java dependa del sistema operativo.

Pero a veces eso está bien, y usted realmente quiere controlar las señales usted mismo.

Aunque no está expuesto como parte de la API oficial de JDK, parte de la JVM tiene que manejar señales (para activar los ganchos de cierre y salir), y ese componente es sun.misc.Signal . Aunque este es un detalle de implementación y, por lo tanto, podría cambiar, es poco probable en la práctica. Si fuera a cambiar, tendría que ser reemplazado por un mecanismo equivalente y probablemente documentado en la Guía de solución de problemas de la plataforma Java .

La clase de hermanos sun.misc.Unsafe se usa ampliamente y no está documentada de manera similar . Hay un trabajo activo para tratar de eliminar esta clase porque es " convertirse en un ''campo de dumping'' para los métodos no estándar pero necesarios ", pero la propuesta actual , aunque limita algunas API no estándar, mantiene ambos sun.misc.Unsafe y sun.misc.Signal disponible por defecto. Un plan anterior para evitar realmente el acceso a estas clases todavía habría incluido un indicador de línea de comando para permitir el acceso a ellas por compatibilidad con versiones anteriores.

En breve, no puede confiar en sun.misc.Signal y debe planificar la eventualidad de que este comportamiento cambie, es muy improbable que este comportamiento cambie antes del JDK 10, y si lo hace, probablemente se introducirá un nuevo mecanismo mejor o habrá una manera razonable de volver a habilitarlo si es necesario.

Sin embargo, sería prudente compartimentar el código que se basa en cualquier clase de sun.misc para un alcance tan pequeño como sea posible: cree una API de sun.misc para el manejo de la señal para que las personas que llaman no tengan que interactuar directamente con sun.misc . De esa manera, si la API cambia, solo necesita cambiar la implementación de su envoltorio, en lugar de todo su código de manejo de señales.

Answer 2

Su mejor apuesta es la transición de las señales, ya que no están bien soportadas.

Alternativas para el IPC:

• Sockets (incluyendo servicios web, JMS, etc.)
• Bloqueo de archivos
• Archivo mapeado de memoria