jsf - Java EE 7，EL 3.0 规范。关于类型强制的变化

Question

所以我已经离开 Java EE 六个月了，现在我回来了并将应用程序迁移到 Java EE 7我注意到 JSR-341/ the EL 3.0 spec.包含类型转换部分的更改(现在是 1.23 部分；以前是 1.18 部分)。

在 1.23 节中，除了 String 之外的所有各种类型的第一条规则是，如果 X 为 null 且 Y 不是原始类型，则返回 null。这是一个非常受欢迎的变化。

所以我的第一个问题是:关于 1.23.3 Coerce A to Number type N，

在 EL 2.1 中:

If A is null or "", return 0.

在 EL 3.0 中:

If A is null and N is not a primitive type, return null.
Else if A is null or "", return 0.

现在是否不再需要设置系统属性 org.apache.el.parser.COERCE_TO_ZERO=false ?

接下来，还有一些其他变化会引发问题:

在第一小节中，第 1.23.1 节(以前的 1.18.1)将值 X 强制为类型 Y，给出了一般情况的规则。现在，添加了一个新项目符号(强调我的):

If X is null and Y is not a primitive type and also not a String, return null.

在 1.23.2 Coerce A to String 一节中，前两个子弹已经被翻转了。它们现在按以下顺序排列:

If A is null: return “”
Otherwise, if A is String: return A

看起来，在强制转换后，空字符串仍然是空字符串，而现在空字符串被强制转换为空字符串。所以我的第二个问题是:我是否正确阅读了这个，现在 String 在强制方面的处理方式与其他类型的对象不同？如果是这样，为什么？

这种变化似乎违反直觉，因为我们都知道 null 具有特殊的含义。此外，这种更改令人担忧，因为它会对我正在迁移的代码产生不利影响，这些代码最初是针对旧规范编写的。

最后，我的第三个问题是:bean 验证怎么样？这是否意味着现在 @NotNull支持 bean 中字符串的注释是无用的，因为强制字符串值永远不能为空？我对此表示怀疑，但我想知道这些新变化是如何协同工作的。

Answer 1

Is it now no longer necessary to set the system property org.apache.el.parser.COERCE_TO_ZERO=false?

当您使用 Apache EL parser (如在其他 Tomcat 中使用的那样)，这是正确的。也就是说，他们确实终于实现了 my own request在那。

鉴于您使用的是 Wildfly，但这应该不适用于您的特定情况，因为它不使用 Apache EL，而只是 EL RI (就像在 GlassFish 中一样)从一开始就已经有了这部分。这只是 EL 规范中的一个小疏忽，Tomcat 人员对此非常挑剔(他们在 Tomcat 6.0.16 之前也有这部分内容，然后对其进行了修改以“遵守”规范中的疏忽，经过很多他们在 6.0.17 中添加了此系统属性以便能够将其关闭)。

am I reading this correctly, that the String is now treated differently than the other kinds of objects with respect to coercion?

不。顺序无关紧要，结果始终相同。 null不是 String反正。为了清晰和简化实现，顺序可能已更改。

从 JSF 的角度来看，这个 EL 规范部分只涉及将 EL 表达式的结果写入 HTML 输出(这是 String 类型)，而不是像您所期望的那样使用提交/强制/转换/验证值更新模型值。为此，您仍然需要以下 web.xml用于让 JSF 将提交的空字符串值解释为 null 的上下文参数:

<context-param>
    <param-name>javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL</param-name>
    <param-value>true</param-value>
</context-param>

与 JSF 2.0/2.1 相比，这部分没有改变。