von Til » 30 Okt 2004, 09:16
Das bringt nicht viel. Es ist blöd, wenn man sich nicht darauf verlassen kann, dass getRowCount() in der nächsten Sekunde sich geändert hat, wenn man es aufruft.
Ich fände besser, wenn alles, was im TableModel gemacht wird, im Swing-Thread zu passieren hat. Dann können wir uns den synchronized-Kram sparen, der ja auch nur bedingt weiterhilft. Es hilft ja niemand was, wenn die Methoden des TableModel selbst synchronisiert sind, aber der aufrufende Kontext nicht.
Ich schlage deshalb vor, dass wir die synchronized-Sachen wieder rauskicken und durch Prüfungen ersetzten, die schauen, dass auch ja der richtige Thread genutzt wird. In der Entwicklerversion können wir bei einer Verletzung eine Exception schmeissen, so finden wir wohl recht schnell alle Stellen, die am Model herumpfuschen und können sie in ein SwingUtilities.invokeLater() verpacken. Danach können wir eine einfache Warnung ausgeben.
Das bringt nicht viel. Es ist blöd, wenn man sich nicht darauf verlassen kann, dass getRowCount() in der nächsten Sekunde sich geändert hat, wenn man es aufruft.
Ich fände besser, wenn alles, was im TableModel gemacht wird, im Swing-Thread zu passieren hat. Dann können wir uns den synchronized-Kram sparen, der ja auch nur bedingt weiterhilft. Es hilft ja niemand was, wenn die Methoden des TableModel selbst synchronisiert sind, aber der aufrufende Kontext nicht.
Ich schlage deshalb vor, dass wir die synchronized-Sachen wieder rauskicken und durch Prüfungen ersetzten, die schauen, dass auch ja der richtige Thread genutzt wird. In der Entwicklerversion können wir bei einer Verletzung eine Exception schmeissen, so finden wir wohl recht schnell alle Stellen, die am Model herumpfuschen und können sie in ein SwingUtilities.invokeLater() verpacken. Danach können wir eine einfache Warnung ausgeben.