jTextField in 'Realtime' aktualisieren

Hallo,
ich habe folgendes Problem: Ich möchte in einem JAVA GUI eine Art Statusfeld mit den aktuellen Logausgaben aktualisieren. Dummerweise erfolgt die Aktualisierung der GUI genau am Ende, wenn jButtonCreateScriptsActionPerformed abgearbeitet ist. Ich möchte aber wäherend der Verarbeitung schon eine Ausgabe erzwingen. Dinge wie
jTextFieldStatus.repaint(); etc haben leider keine Auswirkung. Wie kann ich das lösen? Muß ich einen zweiten Thread starten und dort meine execute Methode ausführen? Hier der Beispielcode:

private void jButtonCreateScriptsActionPerformed(java.awt.event.ActionEvent evt){


String output = SysCall.execute(fSasScriptPath + " " + fOutputPath + „\“ + tmpScriptFileName, jTextFieldStatus);


}

public class SysCall {

/**
* Führt Kommando cmd auf Commandline Ebene aus
*
*/
public static String execute(String cmd,javax.swing.JTextArea jTextFieldStatus){
BufferedReader in;
String text =""; // Lesepuffer
String output ="";
try {
// Prozeß anlegen
Process process = Runtime.getRuntime().exec(cmd);
// Eingabestream holen
in = new BufferedReader(
new InputStreamReader(process.getInputStream()));
// Alle Zeichen aus dem Stream auslesen und
// in LOG ausgeben
while ((text = in.readLine()) != null) {
jTextFieldStatus.repaint(); //wirkungslos
String curStatus = jTextFieldStatus.getText();
jTextFieldStatus.setText(curStatus + Utilities.getTimeStampReadable() + " - " + text + „\n“);
output += text + „\n“;
LOG.debug(text);
}
}
catch (Exception e) {
e.printStackTrace();
}
return output;
}

Moien

Wie kann ich das lösen?

Du missbrauchst derzeit den AWT-Thread zum rechnen. Solange der AWT-Thread in deinem Code unterwegs ist kann sich die GUI nicht verändern.

Muß ich einen zweiten Thread starten
und dort meine execute Methode ausführen?

Ja, das ist Minimum.

Wenn man 100% java-swing threadsafe sein möchte muss noch ein 3. Thread her. Swing-Elemente sind nämlich nicht threadsafe ausgelegt. D.h. nur der AWT-Thread darf swingelemente anfassen. SwingUtils.invokeLater(Runnable r) ist da eigentlich angesagt.

In der Praxis macht das kaum jemand. Fehler durch Threadkollisionen kommen halt verdammt selten vor und der Aufwand ist enorm.

cu