13.1 Swingの一般的なデバッグ・ヒント

なにかしらのメニューがポップアップされた状態で実行されるSwingコードのデバッグを行う場合、デバッガをリモートで使用することをお薦めします。それ以外の場合、デバッグ・プロセスとアプリケーション実行とが互いにブロックし合い、システムでの後続の作業が行えなくなります。それが発生した場合に取れる唯一のアクションは、Oracle SolarisおよびLinuxのXサーバーを終了させることです。詳細は、バグ・データベースでこのバグを参照してください。

次は、いくつかの一般的なSwingの問題です。

• ペイント。

• レンダラ。

• 間違ったスレッドからのモデルの更新。

• ハング。

• 応答性。

• 再描画の問題。

• isOpaqueの使用。

• 起動: 小さなヒープ、不要なクラスのロードが原因である可能性があります。

次は、いくつかの検討事項です:

• 1つのウィンドウにつき1つのバッファの機能。

• ネイティブ・ルック・アンド・フィールの忠実度: Gnome対Windows

• Swingアプリケーションのフットプリント。

• JTable、JTree、およびJListはすべてレンダラを使用します。

• カスタム・レンダラの処理を極力減らすようにします。

• モデルの更新は、イベント・ディスパッチ・スレッドからしか行わないようにします。それ以外の場合、モデルの状態が表示に反映されなくなります。

次は、不適切なレンダラを識別します:

• 動作の遅いアプリケーション(特にスクロール時)。

• オプティマイザを使ってペイント呼出しを監視し、getTableCellTRendererComponentの呼出しを探します。