なぜStringを（finalとして）宣言してから使用するのですか？

典型的なSpring MVCバリデータークラスでは、ErrorsオブジェクトにerrorCode値を挿入するときに、文字列（props.somefield.req）を使用した場合との違いは何ですか？

errors.rejectValue("elementId", "props.somefield.req");

宣言された静的な最後の文字列と対になる？

private static final String SOMFIELD_REQ = "props.somefield.req"; ...
errors.rejectValue("elementId", SOMFIELD_REQ);

少しでもパフォーマンスは向上しますか？スタックオーバーフローに関するいくつかの質問（Stringとfinal、Javaでfinal Stringを定義することは理にかなっていますか）を読みましたが、この質問の更新の質問に答えることはできませんでした。

実行時には、違いはありません。

ポイントは可読性です-メンバー変数として、それはクラスのソースコードの最初に宣言されている可能性が高く、静的にすることはクラスの新しいインスタンスごとに割り当てる必要がないことを意味します。

最終的にすることは、値が変更されないことを読者に示します（コンパイラーにとってもですが、ここではそれほど重要ではありません）。

この方法では、実装に埋め込まれた「魔法の値」はなく、「定数」への変更が必要な場合は、1か所で変更するだけで済みます。

これは基本的に、Cプログラマが#defineで何をするかを模倣しています。

final フィールドには多くの利点があります！

フィールドをとして宣言finalすると、クラスを使用または拡張する開発者にとって重要なドキュメントの利点があります。これは、クラスがどのように機能するかを説明するだけでなく、設計上の決定を実施する際にコンパイラの助けを借ります。finalメソッドの場合とは異なり、最終フィールドを宣言すると、フィールドの値が変更されないことがコンパイラーにわかっていれば、値をレジスターに安全にキャッシュできるため、オプティマイザーは最適化の決定をより適切に行うことができます。finalフィールドは、フィールドが読み取り専用であることをコンパイラーに強制させることにより、安全性のレベルを高めます。

finalパフォーマンス管理ツールとして使用しないでください。プログラムのパフォーマンスを向上させるには、はるかに優れた、制約の少ない方法があります。finalプログラムの基本的なセマンティクスを反映する場所で使用します。クラスが不変であること、またはフィールドが読み取り専用であることを示します。

最終フィールドを宣言する前に、自分自身に問いかける必要があります。このフィールドは本当に変更可能である必要がありますか？