自作のコンバータが動かなくなった。原因は、コンバータの getAsString の戻り値として null が許容されなくなったこと。これが JSF 的に正しくて、前の実装が間違っていたのかは不明。仮にこのメソッドで null を返そうものなら、org.seasar.teeda.core.util.HTMLEncodeUtil ちゃんが、59 行目でヌルポはいてへこたれちゃう。
これ，JSFのRIだとどうなるか試してみた．NetBeansは標準でこのへん抱えてくれてるので試すのが楽チンでいいね．標準ってライブラリの依存関係とかセットアップとかに悩まなくていいのが利点だね．
で，結果．
問題なし．
javax.faces.convert.ConverterのJavaDocを見ると
getAsString
Returns:
a zero-length String if value is null, otherwise the result of the conversion
とかかれている．nullならば長さゼロの文字列を返せ，そうでなければコンバートした結果を返せ，ということらしい．
長さゼロの文字列をnull扱いにしているくらいだからnullはあまり好ましくはないのだろう．だが，コンバートの結果nullを返すという仕組みがあるかもしれない．nullを返すなとかかれていない以上可能性はある．
逆に文字列からObjectを生成する場合を見てみる．
getAsObject
Parameters:
value - String value to be converted (may be null)
Returns:
null if the value to convert is null, otherwise the result of the conversion
入力としてnullが入ってくるかもしれないことを念頭においているということでたぶんStringへのコンバートもnullは大丈夫なんじゃないかなぁ．もっとも，ここでnullが入ってくることは通常ありえないと思うし（長さゼロの文字列が普通はくる），このメソッドでnullを返すとgetAsStringが呼ばれなくなるし．
個人的にはgetAsObjectでnullを返すとgetAsStringが呼ばれなくなる挙動がただしいのかどうかのほうが気になった．getAsString単独で使用しても「may be nul」とかかれているのに，実際はオブジェクトにnullの値を入れるとこのメソッド自体が呼ばれないのはRI特有のものと考えたほうがいいのか．
それともStateHolderと併用した場合だけかなぁ．
この辺は仕様と実装の差が生み出す問題なんだろうけど，nullを返す可能性もあるに一票．
