今まで、StringからIntegerに変換する場合、（主にクライアント側からPKなどのリクエストパラメータを取得する場合）
①Integer.parseInt(str)
②Integer.valueOf(str)
③new Integer(str)
こんな方法を使い、あまり意識して使いわけていなかったが、
①は戻り値がint
②は戻り値がInteger
③はIntegerオブジェクトを生成
と、厳密に違うらしい。
（考察）
①はint型に変換してjavaのオートボクシング機能があったから、勝手に変換してくれてたが無駄に変換する文、冗長な処理だと感じる。
②はIntegerクラスのスタティックなメソッドを使っているかと思われるので、これがこの３つの中だと一番正しいと感じる。
③は一見②とあまり変わらないように見えるが、Integerオブジェクトを無駄に生成しているので、処理的には無駄。・・・きっとすぐガーベージコレクションの対象となってしまうのだろう。
考察してみたが、とりあえず②を使っていれば問題なさそう。
どれも予想なのでどこかのタイミングでAPIを見ることにしよう。
サーバ側での入力チェックはActionMessagesクラスを使い、view側で<html:messages>タグを使うと良い
クライアント側での入力チェックには<html:errors />タグを使い、
エラー内容をまとめて出したい場合にはそのまま使用。
個別に出したい場合は、property属性を使用し、対象となる入力コンポーネントのプロパティ名を指定すると良い。
※これがベストアンサーなのかは定かではない。
バリデータを使用する場合、チェックしたいプロパティが存在するFormクラスを
ActionFormではなくValidatorFormに変更し
validation.xmlにどのバリデーションをするのかを記述する。（必須チェック、長さチェック等）
その際、StrutsConfig内でValidatorFormを継承しているFormを参照していて、バリデートする必要がないアクションには、明示的に validate="false" と記述する必要がある。
デフォルトがvalidate="true"なので、何も設定しないとバリデーションに引っかかる動きをする。
この状態になった際にはフォワード先を指定しているinput="hoge/hoge/foo.jsp"の属性の定義を忘れているケースが多いので、フォワード先の指定がされていない。などのエラーがでる。
バリデートの動きを確認する際には、view側でのエラー表示処理を忘れずに。
