Разница в поведении тернарного оператора в JDK8 и JDK10

Я считаю, что это была ошибка, которая, кажется, была исправлена. Согласно JLS, выбрасывание NullPointerException кажется правильным поведением.

Я думаю, что здесь происходит то, что по какой-то причине в версии 8 компилятор учитывал границы переменной типа, упомянутые возвращаемым типом метода, а не фактические аргументы типа. Другими словами, он думает, что ...get("1") возвращает Object. Это может быть связано с тем, что он рассматривает возможность стирания метода или по какой-либо другой причине.

Поведение должно зависеть от типа возвращаемого значения метода get, как указано в приведенных ниже выдержках из 15.26:

• Если и второе, и третье выражения операнда являются числовыми выражениями, условное выражение является числовым условным выражением.

  В целях классификации условного выражения следующие выражения являются числовыми выражениями:

  • []

  • Выражение вызова метода (§15.12), для которого выбранный наиболее конкретный метод (§15.12.2.5) имеет возвращаемый тип, преобразуемый в числовой тип.

    _{Обратите внимание, что для универсального метода это тип перед созданием экземпляра аргументов типа метода.}

  • []

• В противном случае условное выражение является ссылочным условным выражением.

[]

Тип числового условного выражения определяется следующим образом:

• []

• Если один из второго и третьего операндов имеет примитивный тип T, а тип другого является результатом применения преобразования упаковки (§5.1.7) в T, то тип условного выражения — T.

Другими словами, если оба выражения могут быть преобразованы в числовой тип, и одно является примитивным, а другое упакованным, то тип результата тернарного условного выражения является примитивным типом.

(Таблица 15.25-C также удобно показывает нам, что тип тернарного выражения boolean ? double : Double действительно будет double, что опять же означает правильность распаковки и выбрасывания.)

Если тип возвращаемого значения метода 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"));
    }
}

Это показывает, что поведение компилятора на самом деле различается в зависимости от того, присваивается ли тернарное выражение локальной переменной или параметру метода.

(Первоначально я хотел использовать перегрузки, чтобы доказать фактический тип, который компилятор дает троичному выражению, но это не похоже на то, что это возможно, учитывая указанную выше разницу. Возможно, есть еще один способ, о котором я не подумал, хотя.)

JLS 10, похоже, не указывает никаких изменений в условном операторе, но у меня есть теория.

Согласно JLS 8 и JLS 10, если второе выражение (1.0) имеет тип double, а третье (new HashMap<String, Double>().get("1")) имеет тип Double, то результат условного выражения имеет тип double. JVM в Java 8 кажется достаточно умной, чтобы знать, что, поскольку вы возвращаете Double, нет причин сначала распаковывать результат HashMap#get в double, а затем обратно в Double (потому что вы указали Double).

Чтобы доказать это, замените Double на double в вашем примере, и будет выброшено NullPointerException (в JDK 8); это потому, что сейчас происходит распаковка, и null.doubleValue() явно выдает NullPointerException.

double d = false ? 1.0 : new HashMap<String, Double>().get("1");
System.out.println(d); // Throws a NullPointerException

Кажется, это было изменено в 10, но я не могу сказать вам, почему.