私は Java EE から 6 か月間離れていましたが、現在戻ってきて、アプリケーションをJava EE 7に移行しています。JSR-341/EL 3.0 仕様に気付きました。セクション型変換(現在はセクション 1.23、以前はセクション 1.18)の変更が含まれています。
セクション 1.23 では、 String を除くさまざまな型すべての最初のルールは、X が null で Y がプリミティブでない場合は null を返すというものです。これは非常に歓迎すべき変更です。
したがって、私の最初の質問は次のとおりです。セクション1.23.3 Coerce A to Number type Nに関して、
EL 2.1:
A が null または "" の場合、0 を返します。
EL 3.0 では:
A が null で N がプリミティブ型でない場合は、null を返します。
A が null または "" の場合は、0 を返します。
システム プロパティを設定する必要はなくなりましたorg.apache.el.parser.COERCE_TO_ZERO=falseか?
次に、疑問を投げかける他のいくつかの変更があります。
最初のサブセクション、セクション 1.23.1 (以前の 1.18.1) To Coerce a Value X to Type Yでは、一般的なケースのルールが与えられています。今、新しい箇条書きが追加されました（強調は私のものです）：
X が null で、Y がプリミティブ型でも String でもない場合は、 null を返します。
セクション 1.23.2 Coerce A to Stringでは、最初の 2 つの箇条書きが反転しています。それらは現在、次の順序になっています。
A が null の場合: return “”<br> それ以外の場合、A が String の場合: return A
以前は null 文字列は強制後に null 文字列のままでしたが、現在は null 文字列が空の文字列に強制されているようです。私の 2 番目の質問は、強制に関して、文字列が他の種類のオブジェクトとは異なる方法で扱われるようになったことを正しく読んでいますか? もしそうなら、なぜですか？
null には特別な意味があることは誰もが知っているため、このような変更は直感に反するように思えます。さらに、このような変更は、私が移行しようとしているコードに悪影響を与える可能性があるため、憂慮すべきものです。このコードは、もともと古い仕様に対して書かれていました。
最後に、私の 3 番目の質問は、Bean の検証についてはどうですか? これは@NotNull、強制された文字列値が null になることは決してないため、バッキング Bean の文字列の注釈は役に立たないということですか? 疑わしいですが、新しい変更がどのように連携するか知りたいです。