Swing e processo esterno.

[Samaritan]

Corretto sì, lo è. Si potrebbe far notare una cosa però. Il exec() avvia il processo in modo asincrono, ovvero exec è praticamente immediato. Se non devi attendere la fine del processo per prendere il suo exit-code e non devi fornire al processo dati continui su standard-input oppure leggere i suoi standard-output/error, allora il nuovo thread a parte non servirebbe nemmeno tanto.

Detto però meglio in generale: se il processo lanciato scrive molto su standard-output/error allora tale output deve essere letto lato Java, altrimenti il processo può bloccarsi (questioni di buffering). Quindi un thread a parte ci vorrebbe veramente.

Ti ringrazio molto per la completezza della tua risposta perché oltre a darmi una utile conferma di quanto ho fatto, mi hai anche tolto un dubbio che avevo e non avevo proprio esposto e cioè se la lettura degli InputStream dell'oggeto Process fosse una opzione oppure un obbligo.
Siccome il contenuto di questo stream non mi interessa più di tanto e neppure il suo exitCode, visto che se in un ciclo dovesse esserci qualche problema non conterebbe più di tanto, poiché questi cicli di generazione/invio dei files avvengono ogni 30 secondi.
Da quello che mi hai scritto invece sembra essere molto importante che io legga di volta in volta questo InputStream del processo(anche se non mi interessa il suo contenuto), gestendo tutto in un try-catch con un finally che provvederebbe di volta in volta a garantire la chiusura dello stream stesso.
Attualmente ho aggiunto questo thread aggiuntivo all'edt soltanto per fare in modo che si instaurasse un contesto concorrente tra l'edt ed il processo di invio dei files che può richiedere diversi secondi per concludersi.
Ma se tu mi scrivi che già internamente l'utilizzo di Runtime.exec crea di suo un nuovo thread, allora mi pare di capire che questo nuovo thread che ho aggiunto per non influenzare l'edt sia praticamente inutile per questo scopo.
Quindi l'unica causa plausibile che ogni tanto ha causato dei veri e propri dead-locks dell'applicativo non può che risiedere nella saturazione del buffer utilizzato dalla jvm per salvare l'output del processo.
Mi confermi quindi che è fondamentale che io legga l'inputstream e l'errorstream del processo e provveda sempre a chiudere questi stream ad ogni ciclo di invocazione dell'eseguibile esterno in modo da liberare tutte le risorse utilizzate da questi stream del processo e scongiurare il rischio di dead-lock del'applicativo?
Confermo che l'acquisizione dei due stream del processo che recentemente avevo pensato di escludere era già stata fatta in un altro suo thread specifico che provvedeva a leggerne il contenuto e che chiudeva gli stream alla fine.
Inoltre il processo non richiede l'invio continuo di dati e non manda neppure uno stream lungo che richiede grossi buffer per potere essere memorizzato e letto.
E' semplicemente un eseguibile che rimane sempre attivo e non si conclude mai.
Per questo non sono potuto rimanere in attesa del suo exitCode e neppure fare un join sul thread che ne gestisce l'inputstream e l'errorstream per mettere in attesa il current-thread fino a quando tali stream si concludevano.
Proprio perché non c'è alcuna uscita del processo stesso ed a Swing interessa soltanto che questo processo venga avviato e che inizi a generare periodicamente questi files ogni 30 secondi.
Swing non deve fare altro che eseguire questo processo esterno una sola volta all'avvio e poi reinviare tali files ogni 30 secondi.
La fase di invio dei file al server remoto è ovviamente la cosa più dispendiosa in termini di tempo ed è per questo che avevo pensato di creare un altro thread che la gestisse.
Forse ora mi sono spiegato meglio sul sistema.
Grazie di nuovo.