JList setListData Threading Probleme

Question

Ich lade Inhalt einer Datei zu JList Komponente. Wenn ich das Laden im Hauptthread mache, scheint alles in Ordnung zu sein - Inhalt wird geladen. Aber wenn ich Ladecode in einen separaten Thread verschiebe, wähle ein Element in einer Liste aus und versuche, die Liste neu zu laden, bekomme ich zufällige NullPointer oder IndexOutOfBounds Ausnahmen. Ich bin mir sicher, dass dies eine Art Swing-Threading-Problem ist, aber nicht bestimmen kann, was.

Das ist mein Thread-Code:

@Override 
public void run() { 
    List<String> textLines = null; 
    textLines = splitter.split(model.getLedMaxChars(), textLoader.loadText(file)); 
    listener.onTextLoaded(textLines);//listener is in main Swing code 
} 

Controller ist für das Hören verantwortlich:

@Override 
public void onTextLoaded(List<String> textLines) { 
    view.fileLoaded(model.getCurrentFile()); 
    view.setTextLines(textLines); 
    view.enableListComponent(); 
} 

Und die Aussicht Updates:

public void setTextLines(List<String> textLines) { 
    jList.setListData(textLines.toArray()); 
} 

Ich habe versucht Thread zu lassen hängen Sie, indem Sie while(true); Schleife hinzufügen - dann funktioniert alles OK. Wenn ich erneut lade, ohne das Element in einer Liste auszuwählen, funktioniert alles auch.

Kann mir jemand erklären, was ich hier vermisse?

Answer 1

Swing-Komponenten sind normalerweise nicht gewindesicher. Das bedeutet, dass nur der Swing-Worker-Thread alle Änderungen tun sollten:

Runnable worker = new Runnable() { 
    public void run() { 
    jList.setListData(textLines.toArray()); 
    } 
}; 
SwingUtilities.invokeLater(worker); 

Siehe auch:

• http://java.sun.com/products/jfc/tsc/articles/threads/threads1.html
• http://java.sun.com/products/jfc/tsc/articles/threads/threads2.html

Answer 2

Schaukel ist nicht Thread-sicher, so dass, wenn Sie Manipulieren von GUI-Elementen aus anderen Threads kann viele seltsame Dinge auftreten. In Ihrem Fall die einfachste Lösung (aber wahrscheinlich nicht die beste) wäre SwingUtilities.invokeLater