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

所以我已经离开 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 中:



在 EL 3.0 中:



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

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

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



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



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

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

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

最佳答案

当您使用 Apache EL parser(如 Tomcat 中使用的)时，这是正确的。换句话说，他们确实最终实现了 my own request 。

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



不。顺序无关紧要，结果始终相同。 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 相比，这部分没有改变。

关于jsf - Java EE 7，EL 3.0 规范。关于类型强制的变化，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/23879367/