三元运算符无法识别Eclipse中的编译错误

Question

我正在使用Eclipse作为IDE，并具有以下代码

List<Long> countList = new ArrayList<>();
Long count = (countList != null && !countList.isEmpty()) ? countList.get(0) : 0;

在Eclipse中，else的自动装箱会产生编译错误，但不会。 我也尝试了最新的Eclipse版本Photon，但仍然相同。

但是，当我使用Jenkins构建项目时，它会抛出适当的编译错误。 有人可以建议如何解决此问题吗？

我尝试了设置Preferences -> Errors/Warnings -> Boxing and unboxing conversions ，并将默认行为从警告变为错误。 但这也会导致其他不必要的错误。

有没有一种方法可以通过日食设置解决此问题？

Answer 1

这不是Eclipse中的错误，而是javac的错误。 它仅影响Java 8，因此使用其他版本可以解决此问题。

注意，虽然像Long var = 0;这样的构造Long var = 0; 规范不允许，条件表达式是一个完全不同的字段。

Java语言规范中有关“ 条件运算符？ ： ”具有数值条件表达式的概念，甚至显式包含一个转换表 ，该表显示Long类型的第二个参数和int类型的第三个参数的组合应该是有效的，其结果类型为“ bnp(Long,int) ” ，而“ bnp”代表“ 二进制数字推广 ”¹

_{¹我故意链接到规范的Java 8版本，该版本是javac表现出这种错误行为的版本。}

简而言之，这意味着在需要时取消装箱，然后在需要时扩大原始转换，最后，在需要时将结果再次装箱。

请注意，只要不涉及通用方法，即使Java 8的javac都能正确执行此操作：

Long boxed = !countList.isEmpty()? countList.get(0): null;
Long count = boxed != null? boxed: 0;// promotes int to Long

不产生编译器错误。

JDK-8162708中已描述了涉及泛型方法时产生编译器错误的行为， 以及三元运算符和泛型方法的意外语法错误 。 它还提到javac确实在Java 7和Java 9下正确处理了此构造，因此问题仅在Java 8中发生。我还验证了在Java 11和Java 12的当前状态下未出现编译器错误。

值得指出的是，上述规则可能具有违反直觉的行为。 例如

boolean someCondition = true;
Long variable = null;
Long other = someCondition? variable: 0;

将抛出NullPointerException ，因为未传递存储在variable的引用，但将取消装箱并再次装箱。

同样，

Integer variable = 42;
Long other = variable;

不是有效的分配，但

Integer variable = 42;
Long other = true? variable: 0L;

是。