4

所以我已经离开 Java EE 六个月了，现在我回来并将应用程序迁移到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）中，为了将值 X 强制转换为类型 Y，给出了一般情况的规则。现在，添加了一个新项目符号（强调我的）：

如果 X 为 null 且 Y 不是原始类型也不是 String，则返回 null。

在 1.23.2 Coerce A to String部分中，前两个项目符号已翻转。它们现在按以下顺序排列：

如果 A 为空：返回“”<br> 否则，如果 A 为字符串：返回 A

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

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

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

4

1 回答 1

4

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

当您使用Apache EL 解析器（在其他 Tomcat 中使用）时，这是正确的。换句话说，他们确实最终实现了我对此的要求。

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

我读对了吗，String 现在在强制方面的处理方式与其他类型的对象不同吗？

没有。顺序无关紧要，结果始终相同。反正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 相比没有变化。

于 2014-05-27T05:06:45.930 回答