Возврат null как int разрешен с тернарным оператором, но не с оператором if

Давайте посмотрим на простой код Java в следующем фрагменте:

public class Main {

    private int temp() {
        return true ? null : 0;
        // No compiler error - the compiler allows a return value of null
        // in a method signature that returns an int.
    }

    private int same() {
        if (true) {
            return null;
            // The same is not possible with if,
            // and causes a compile-time error - incompatible types.
        } else {
            return 0;
        }
    }

    public static void main(String[] args) {
        Main m = new Main();
        System.out.println(m.temp());
        System.out.println(m.same());
    }
}

В этом простейшем Java-коде temp()метод не выдает ошибку компилятора, хотя возвращаемый тип функции - это int, и мы пытаемся вернуть значение null(через оператор return true ? null : 0;). При компиляции это, очевидно, вызывает исключение времени выполнения NullPointerException.

Тем не менее, оказывается , что то же самое , это не так , если мы представляем трехкомпонентный оператор с ifутверждением (как в same()методе), который делает выдает ошибку во время компиляции! Зачем?

Компилятор интерпретирует nullкак нулевую ссылку на an Integer, применяет правила автоматической блокировки / распаковки для условного оператора (как описано в спецификации языка Java, 15.25 ) и успешно перемещается дальше. Это создаст NullPointerExceptionво время выполнения, что вы можете подтвердить, попробовав его.

Я думаю, компилятор Java интерпретирует true ? null : 0как Integerвыражение, которое можно неявно преобразовать в int, возможно, дать NullPointerException.

Во втором случае выражение nullимеет специальный нулевой тип see , поэтому код return nullделает несоответствие типов.

На самом деле, все это объясняется в спецификации языка Java .

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

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

Поэтому "null" в вашем (true ? null : 0)получает тип int, а затем автоматически упаковывается в Integer.

Попробуйте что-то подобное, чтобы убедиться в этом, (true ? null : null)и вы получите ошибку компилятора.

В случае ifоператора nullссылка не рассматривается как Integerссылка, потому что она не участвует в выражении, которое заставляет его интерпретироваться как таковое. Поэтому ошибка может быть легко обнаружена во время компиляции, потому что это более четко ошибка типа .

Что касается условного оператора, спецификация языка Java §15.25 «Условный оператор ? :» хорошо отвечает на это в правилах о том, как применяется преобразование типов:

• Если второй и третий операнды имеют одинаковый тип (который может быть нулевым типом), то это тип условного выражения.
  
  Не применяется, потому что nullнет int.

---

• Если один из второго и третьего операндов имеет тип boolean, а тип другого имеет тип Boolean, то тип условного выражения является логическим.
  
  Не применяется потому , что ни nullни intне booleanили Boolean.

---

• Если один из второго и третьего операндов имеет нулевой тип, а тип другого является ссылочным типом, то тип условного выражения является этим ссылочным типом.
  
  Не применяется, потому что nullимеет нулевой тип, но intне является ссылочным типом.

---

• В противном случае, если второй и третий операнды имеют типы, которые можно преобразовать (§5.1.8) в числовые типы, то существует несколько случаев: […]
  
  Применяется:null рассматривается как преобразуемый в числовой тип и определен в §5.1. 8 «Распаковка конверсии», чтобы бросить NullPointerException.

Первое, что нужно иметь в виду, это то, что троичные операторы Java имеют «тип», и именно это компилятор будет определять и учитывать независимо от того, что является действительным / реальным типом второго или третьего параметра. В зависимости от нескольких факторов тип троичного оператора определяется по-разному, как показано в спецификации языка Java 15.26.

В приведенном выше вопросе мы должны рассмотреть последний случай:

В противном случае второй и третий операнды имеют типы S1 и S2 соответственно. Пусть T1 будет типом, который получается в результате применения преобразования в бокс для S1 , и пусть T2 будет типом, который получается в результате применения преобразования в бокс в S2 . Тип условного выражения является результатом применения преобразования захвата (§5.1.10) к lub (T1, T2) (§15.12.2.7).

Это, безусловно, самый сложный случай, когда вы смотрите на применение преобразования захвата (§5.1.10) и больше всего на lub (T1, T2) .

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

Например, если вы попробуете следующее:

long millis = System.currentTimeMillis();
return(true ? new java.sql.Timestamp(millis) : new java.sql.Time(millis));

Вы заметите, что результирующий тип условного выражения - java.util.Dateэто «Наименьший общий суперкласс» для пары Timestamp/ Time.

Так как nullможет быть автоматически помещен во что угодно, «Наименьший общий суперкласс» является Integerклассом, и это будет тип возврата условного выражения (тернарный оператор) выше. Тогда возвращаемое значение будет нулевым указателем типаInteger и именно это будет возвращено троичным оператором.

Во время выполнения, когда виртуальная машина Java распаковывает , выбрасывается Integera NullPointerException. Это происходит потому, что JVM пытается вызвать функцию null.intValue(), где nullесть результат автобоксирования.

По моему мнению (и поскольку мое мнение не в спецификации языка Java, многие люди все равно сочтут его неправильным), компилятор плохо справляется с оценкой выражения в вашем вопросе. Учитывая, что вы написали, true ? param1 : param2компилятор должен сразу определить, что nullбудет возвращен первый параметр -, и это должно вызвать ошибку компилятора. Это похоже на то, когда вы пишете, while(true){} etc...и компилятор жалуется на код под циклом и помечает его как Unreachable Statements.

Ваш второй случай довольно прост, и этот ответ уже слишком длинный ...;)

ИСПРАВЛЕНИЕ:

После другого анализа я считаю, что я был неправ, говоря, что nullзначение может быть упаковано / автоматически упаковано для чего угодно. Говоря о классе Integer, явный бокс состоит в вызове new Integer(...)конструктора или, возможно, Integer.valueOf(int i);(я где-то нашел эту версию). Первый бросил бы NumberFormatException(а этого не происходит), а второй просто не имел бы смысла, поскольку не intможет быть null...

На самом деле, в первом случае выражение может быть оценено, поскольку компилятор знает, что оно должно быть оценено как a Integer, однако во втором случае тип возвращаемого значения ( null) не может быть определен, поэтому его нельзя скомпилировать. Если вы Integerприведете его к , код скомпилируется.

private int temp() {

    if (true) {
        Integer x = null;
        return x;// since that is fine because of unboxing then the returned value could be null
        //in other words I can say x could be null or new Integer(intValue) or a intValue
    }

    return (true ? null : 0);  //this will be prefectly legal null would be refrence to Integer. The concept is one the returned
    //value can be Integer 
    // then null is accepted to be a variable (-refrence variable-) of Integer
}

Как насчет этого:

public class ConditionalExpressionType {

    public static void main(String[] args) {

        String s = "";
        s += (true ? 1 : "") instanceof Integer;
        System.out.println(s);

        String t = "";
        t += (!true ? 1 : "") instanceof String;
        System.out.println(t);

    }

}

Вывод правда, правда.

Цвет Eclipse кодирует 1 в условном выражении как автоматически упакованный.

Я предполагаю, что компилятор видит возвращаемый тип выражения как Object.