Swingコンポーネントへのすべてのアクセスは、JavaDoc APIドキュメントで特に明記されていないかぎり、イベント・ディスパッチ・スレッド上で行われる必要があります。これには、Swingコンポーネントに接続されるすべてのモデル(TableModelやListModelなど)も含まれます。

Swingの不正な使用をチェックする最良の方法は、次の例で示される計測RepaintManagerを使用することです。

public class CheckThreadViolationRepaintManager extends RepaintManager {
     // it is recommended to pass the complete check
     private boolean completeCheck = true;

     public boolean isCompleteCheck() {
         return completeCheck;
     }

     public void setCompleteCheck(boolean completeCheck) {
         this.completeCheck = completeCheck;
     }

     public synchronized void addInvalidComponent(JComponent component) {
         checkThreadViolations(component);
         super.addInvalidComponent(component);
     }

     public void addDirtyRegion(JComponent component, int x, int y, int w, int 
h) {
         checkThreadViolations(component);
         super.addDirtyRegion(component, x, y, w, h);
     }

     private void checkThreadViolations(JComponent c) {
         if (!SwingUtilities.isEventDispatchThread() && (completeCheck || 
c.isShowing())) {
             Exception exception = new Exception();
             boolean repaint = false;
             boolean fromSwing = false;
             StackTraceElement[] stackTrace = exception.getStackTrace();
             for (StackTraceElement st : stackTrace) {
                 if (repaint && st.getClassName().startsWith("javax.swing.")) {
                     fromSwing = true;
                 }
                 if ("repaint".equals(st.getMethodName())) {
                     repaint = true;
                 }
             }
             if (repaint && !fromSwing) {
                 //no problems here, since repaint() is thread safe
                 return;
             }
             exception.printStackTrace();
         }
     }
}

モデルをnullに設定しなかった場合、モデルがComponentへの参照を保持しているため、ウィンドウ内のコンポーネントはすべて、ガベージ・コレクションの対象外となります。次の例を見てみましょう。

TableModel myModel = ...;
JFrame frame = new JFrame();
frame.setContentPane(new JScrollPane(new JTable(myModel)));
frame.dispose();

アプリケーションがまだmyModelへの参照を保持している場合、frameとそのすべての子には、引き続きmyModelにインストールされたリスナーJTable経由で到達できます。解決方法は、table.setModel(new DefaultTableModel())を呼び出すことです。

たとえば、重量コンポーネントは内部フレームでは機能しません。ユーザーが内部フレームの周辺をドラッグすると、他の内部フレームと重複してしまうためです。重量コンポーネントを使用する場合は、次のメソッドを呼び出します。

Synth,を使用するには、ルック・アンド・フィールを構成する完全なXMLファイルを用意するか、あるいはSynthLookAndFeelを拡張して独自のSynthStyleFactoryを提供します。

この状況を検出する方法の1つは、処理時間の長すぎるイベントが発生した際にロギング情報を出力できる、新しいEventQueueをプッシュすることです。このアプローチは、フォーカス・イベントやモーダリティに問題があるので完璧とは言えませんが、アドホックなテストには有効です。

たとえば、JPanelクラスのデフォルトはFlowLayoutですが、JFrameクラスのデフォルトはBorderLayoutです。この状況は、1つのLayoutManagerを指定することで簡単に解決されます。

このため、ユーザーがMouseListenerをコンポーネントに接続しても、そのコンポーネントにMouseListenerオブジェクトを持つ子孫が含まれていれば、ユーザーのMouseListenerオブジェクトが呼び出されることは決してありません。

このことは、編集可能なJComboBoxのような複合コンポーネントで容易に再現されます。JComboBoxにはMouseListenerを持つ子コンポーネントが含まれているため、編集可能なJComboBoxに接続されたMouseListenerが通知を受け取ることは決してありません。

ユーザーのMouseListenerが突然イベントを取得しなくなった場合、それは、アプリケーション内でなんらかの変化が生じ、それによって子孫コンポーネントの1つがMouseListenerを持つようになった結果である可能性があります。これをチェックする良い方法は、子孫に対して繰返し処理を実行し、各子孫がマウス・リスナーを持っているかどうかを確認することです。

KeyListenerクラスでも似たようなシナリオが発生します。KeyListenerオブジェクトは、フォーカスされたコンポーネントにしかディスパッチされません。

JComboBoxのケースはこの状況のもう1つの例です。編集可能なJComboBoxの場合、JComboBoxではなくエディタがフォーカスを得ます。結果として、編集可能なJComboBoxに接続されたKeyListenerが通知を受け取ることは決してありません。

トップ・レベルのSwingコンポーネントに追加されるコンポーネントはコンテンツ・ペインに追加される必要がありますが、JFrame、JWindowおよびJDialogクラスのaddメソッド(およびいくつかのほかのメソッド)はコンテンツ・ペインにリダイレクトされます。つまり、frame.getContentPane().add(component)はframe.add(component)と同じです。

次のメソッドはコンテンツ・ペインに自動的にリダイレクトされます。add (およびそのバリアント)、remove (およびそのバリアント)、setLayout。

これは非常に便利ですが、混乱を招く恐れもあります。特に、getChildren、getLayout、およびその他の各種メソッドは、コンテンツ・ペインにリダイレクトされません。

この変更は、GroupLayoutやBoxLayoutなどの1つのコンポーネントのみを処理するLayoutManagerに影響を及ぼします。たとえば、新しいGroupLayout(frame)は機能しません。かわりに、GroupLayout(frame.getContentPane())を使用する必要があります。

JFileChooserでは標準のWindowsファイル・チューザと違って、ファイル・システムの参照時にWindowsショートカットを辿ることができません。ファイルへの正しいパスが表示されないからです。

問題を再現するためのステップ: