我相信这是一个似乎已经修复的错误。根据JLS的说法，抛出a似乎是正确的行为。NullPointerException
我认为这里发生的事情是，由于某种原因，在版本8中，编译器考虑了方法的返回类型中提到的类型变量的边界，而不是实际的类型参数。换句话说，它认为返回 。这可能是因为它正在考虑该方法的擦除或其他原因。...get("1")Object
该行为应取决于方法的返回类型，如以下摘自 §15.26 的摘录所示：get
[...]
数值条件表达式的类型确定如下：
换句话说，如果两个表达式都可以转换为数值类型，并且一个是基元的，另一个是盒装的，则三元条件的结果类型是基元类型。
（表 15.25-C 也方便地向我们表明，三元表达式的类型确实是 ，再次意味着拆箱和投掷是正确的。boolean ? double : Doubledouble
如果该方法的返回类型不可转换为数值类型，则三元条件将被视为“引用条件表达式”，并且不会发生取消装箱。get
另外，我认为注释“对于泛型方法，这是实例化方法的类型参数之前的类型”不应该适用于我们的情况。 不声明类型变量，因此根据 JLS 的定义，它不是泛型方法。但是，此注释是在Java 9中添加的（这是唯一的更改，请参阅JLS8），因此它可能与我们今天看到的行为有关。Map.get
对于 ，的返回类型应为 。HashMap<String, Double>getDouble
这里有一个MCVE支持我的理论，即编译器正在考虑类型变量边界而不是实际的类型参数：
class Example<N extends Number, D extends Double> {
N nullAsNumber() { return null; }
D nullAsDouble() { return null; }
public static void main(String[] args) {
Example<Double, Double> e = new Example<>();
try {
Double a = false ? 0.0 : e.nullAsNumber();
System.out.printf("a == %f%n", a);
Double b = false ? 0.0 : e.nullAsDouble();
System.out.printf("b == %f%n", b);
} catch (NullPointerException x) {
System.out.println(x);
}
}
}
该程序在 Java 8 上的输出为：
a == null
java.lang.NullPointerException
换句话说，尽管具有相同的实际返回类型，但仅被视为“数值表达式”。这些方法之间的唯一区别是类型变量绑定。e.nullAsNumber()e.nullAsDouble()e.nullAsDouble()
可能还有更多的调查可以做，但我想发布我的发现。我尝试了很多事情，发现错误（即没有unboxing/ NPE）似乎只有在表达式是返回类型中具有类型变量的方法时才会发生。
有趣的是，我发现下面的程序也加入了Java 8：
import java.util.*;
class Example {
static void accept(Double d) {}
public static void main(String[] args) {
accept(false ? 1.0 : new HashMap<String, Double>().get("1"));
}
}
这表明编译器的行为实际上是不同的，这取决于三元表达式是分配给局部变量还是方法参数。
（最初我想使用重载来证明编译器为三元表达式提供的实际类型，但考虑到上述差异，这似乎是不可能的。不过，可能还有另一种我没有想到的方法。
