JFormattedTextFieldのcommitEdit()

JTextFieldは、フォーカスイベントに書式変換処理を書かなくても、フィールドの入力値を確定したタイミングで指定したフォーマットに変換する機能がある。

その際に利用するのが、JFormattedTextFieldでこれをカスタマイズしてJTextFieldに登録すると対象のテキストフィールドからフォーカスが離れた時に、フォーマット変換処理が走る。
この詳しいやり方はかかないけど、このJFormattedTextFieldのcommitEdit()というメソッドについて気づいたことをまとめる。

javadocによると以下の通り

【commitEdit】
public void commitEdit()
throws ParseException
現在の値を AbstractFormatter から強制的に取得し、現在の値として設定します。AbstractFormatter が現在インストールされていない場合は何も実行しません。
例外:
ParseException - AbstractFormatter が現在の値をフォーマットできない場合

実は、すでにフォーマット処理が完了しテキストフィールドにト変換後の文字列が入っている場合にこのcommitEdit()を実行すると、その変換後の文字列に対して再度フォーマット処理を行ってしまう･･･(汗)

日付をあらわす数値(20080405など)を入れると、自動的に年度や年月、西暦、和暦などのフォーマットに変換してくれるテキストフィールドの年月変換処理部分の変換ミスを調査した
※和暦を入れると数値に変換しなおして返してくれる。
途中の変換はうまくいってるはずなのに、最終結果が意図通りに表示されない。
よくよく追って見ると、setText()の後に、commitEdit()処理が呼ばれている。

いったい何が起こっているのかというと･･･

1.setText()のタイミングで数値(19890107)⇒和暦年(昭和63年)となる。
2.commitEdit()のタイミングで、平成20年⇒数値(19890601)※月は分からないので実行日の月が設定される。
3.再度フォーマットが走り、数値(19890601)⇒和暦年(平成元年)

大雑把にいうとこんな感じの処理が走って意味の分からない変換が起こったように見える。

ちなみに、commitEdit()をコメントアウトしてみると、1.のフォーマットのみが行われてこちらの意図通りの動きとなり、他の動作にも特に影響はない(たぶん)。
念のため呼び出しておいたんやろうと思うけど、こんな恐ろしい結果につながるとはね･･･（；ω；）

とりあえず、普通の使い方していればcommitEdit()自体はわざわざ呼び出さなくても良いのかな。(勝手にコミットされてる?)
おぼえとこ。