我相信这是一个bug，似乎已经被修复了。按照JLS的规定，抛出NullPointerException似乎是正确的行为。
我认为这里发生的情况是，由于某种原因，在版本8中，编译器考虑的是方法返回类型中提到的类型变量的边界，而不是实际的类型参数。换句话说，它认为...get("1")返回Object。这可能是因为它正在考虑方法的擦除，或者其他原因。
行为应该取决于get方法的返回类型，正如下面从§15.26摘录的所示：
如果第二个和第三个操作数表达式都是数字表达式，则条件表达式是数字条件表达式。为了分类条件，以下表达式是数字表达式：
- 具有可转换为数字类型的返回类型的已选择最具体方法（§15.12.2.5）的方法调用表达式（§15.12）。
- 其他表达式。
否则，条件表达式是引用条件表达式。数字条件表达式的类型如下确定：
- 如果第二个和第三个操作数中的一个是原始类型T，并且另一个的类型是应用装箱转换（§5.1.7）到T的结果，则条件表达式的类型为T。
换句话说，如果两个表达式都可以转换为数字类型，并且其中一个是原始类型，另一个是装箱类型，则三元条件表达式的结果类型是原始类型。
如果
get方法的返回类型不能转换为数字类型，那么三元条件运算符将被视为“引用条件表达式”，不会发生拆箱操作。
另外，我认为注释
“对于泛型方法，这是实例化方法类型参数之前的类型”不适用于我们的情况。
Map.get没有声明类型变量
，因此按照JLS的定义它不是一个泛型方法。但是，这个注释在Java 9中被添加了（是唯一的改变
，参见JLS8），所以它可能与我们今天看到的行为有关。
对于一个
HashMap<String, Double>，
get方法的返回类型
应该是
Double。
下面是支持我的理论的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()被视为“数字表达式”。两种方法之间唯一的区别是类型变量绑定。
可能还可以进行更多的调查，但我想发布我的发现。我尝试了很多事情，并发现当表达式是具有返回类型中的类型变量的方法时，该错误（即无拆箱/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"));
}
}
那表明编译器的行为实际上是不同的，取决于三元表达式是分配给本地变量还是方法参数。
（最初我想使用重载来证明编译器正在给予三元表达式的实际类型，但是鉴于以上差异，看起来似乎不可能。不过，可能还有其他我没有想到的方法。）
false ? 1.0 : (Double) null在两个 JDK 版本中（JDK 1.8.0_144 和 JDK 10.0.1）都会抛出NPE异常，而new HashMap<...>...版本只会在 JDK 10.0.1 中抛出异常。 - Turing85double，因此应该取消装箱。 - Radiodef