Alternativa a sun.misc.Signal

Question

Ho iniziato la ricerca per trovare un'alternativa alla classe sun.misc.Signal, perché potrebbe non essere supportata nei prossimi JDK (stiamo attualmente lavorando su 1.6). Quando costruisco il progetto ottengo:

avvertimento: sun.misc.SignalHandler è Sun API proprietarie e possono essere rimosso in una versione futura

mi sono imbattuto in molteplici soluzioni, ma non lo faccio adattare il mio progetto ad es in this question.

Questo è inaccettabile nella mia situazione, perché:

• I segnali vengono utilizzati non solo per uccidere applicazione
• L'applicazione è enorme - ogni cambiamento concettuale della comunicazione tra i moduli/JVM potrebbe richiedere anni per attuare

Quindi, la soluzione auspicabile è trovare qualcosa come una nuova versione Oracle di questa classe o qualcosa che funzioni allo stesso modo. Esiste una soluzione del genere?

Answer 1

La soluzione migliore è quella di allontanarsi dai segnali poiché non sono ben supportati.

Alternative per IPC:

• Sockets (compresi i servizi web, JMS, ecc)
• File bloccaggio
• memoria mappata file di

Answer 2

come si trova ripetuto all'infinito quando si impara sulla gestione dei segnali in Java, sei incoraggiato a evitare di scrivere codice Java che dipende direttamente dai segnali. La migliore pratica generale è quella di consentire alla JVM di uscire normalmente su ctrl + c e altri segnali registrando uno shutdown hook invece. La gestione dei segnali rende direttamente dipendente il tuo programma Java.

Ma a volte va bene, e davvero, davvero vuoi gestire i segnali da solo.

Anche se non è esposto come parte dell'API JDK ufficiale, parte della JVM deve gestire i segnali (per attivare gli hook di chiusura e uscire), e tale componente è sun.misc.Signal. Sebbene si tratti di un dettaglio di implementazione e pertanto potrebbe cambiare, è improbabile nella pratica. Se dovesse cambiare, dovrebbe essere sostituito con un meccanismo equivalente e probabilmente documentato nello Java Platform Troubleshooting Guide.

La classe di fratello sun.misc.Unsafe è ampiamente utilizzata ed è similarly undocumented. C'è un lavoro attivo per cercare di rimuovere questa classe perché è "become a 'dumping ground' for non-standard, yet necessary, methods", ma il current proposal, pur limitando alcune API non standard, mantiene sia sun.misc.Unsafe sia sun.misc.Signal disponibili per impostazione predefinita. Un piano precedente per impedire effettivamente l'accesso a queste classi avrebbe comunque incluso un flag della riga di comando per consentire l'accesso a tali file per la compatibilità con le versioni precedenti.

Insomma pur non si può contare su sun.misc.Signal e must piano per l'eventualità che questo cambiamenti di comportamento, è altamente improbabile che questo comportamento cambierà prima di JDK 10, e se lo fa sia un nuovo, il meccanismo migliore sarà probabilmente introdotta o ci sarà un modo ragionevole per riattivarlo se necessario.

Tuttavia sarebbe saggio per compartimentazioni codice basato su eventuali sun.misc ramo alle il minor spazio possibile - creare un'API di incarto per la gestione dei segnali in modo che i chiamanti non hanno bisogno di interagire direttamente con sun.misc. In questo modo, se l'API cambia, devi solo cambiare l'implementazione del tuo wrapper, piuttosto che tutto il tuo codice di gestione del segnale.