Quote Originariamente inviata da Samaritan Visualizza il messaggio
non ho quindi utilizzato gli oggetti di Swing per eseguire l'upload dei files in un altro thread come SwingUtilities.invokeLater o SwingWorker e sincronizzare il tutto con l'EDT
invokeLater non sarebbe stato comunque utile nel tuo caso. invokeLater fa eseguire qualcosa "appena possibile" ma comunque nel contesto del EDT.
SwingWorker invece fa eseguire quel qualcosa in un thread separato ma facilita la interazione con la GUI (nel EDT) nel caso il "lavoro" debba fare, di tanto in tanto, qualche aggiornamento sulla interfaccia utente.

Quote Originariamente inviata da Samaritan Visualizza il messaggio
visto che questo processo che genera ed invia i files al server non interferisce minimamente con ciò che viene mostrato nella gui.
Ho semplicemente provveduto a creare un nuovo Thread a cui ho passato un oggetto Runnable nel cui metodo run() ho fatto tutto.
Poi ho settato questo thread come daemon thread e l'ho avviato con start().

Per invocare l'eseguibile esterno ho ovviamente utilizzato l'oggetto Runtime di java con un normale Runtime.exec(...) all'interno del metodo run() del Runnable passato al Thread.
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.