Devolver nulo como int permitido con operador ternario pero no si declaración

Veamos el código Java simple en el siguiente fragmento:

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());
    }
}

En este código Java más simple, el temp()método no emite ningún error del compilador a pesar de que el tipo de retorno de la función es int, y estamos tratando de devolver el valor null(a través de la declaración return true ? null : 0;). Cuando se compila, esto obviamente causa la excepción de tiempo de ejecución NullPointerException.

Sin embargo, parece que lo mismo está mal si representamos el operador ternario con una ifdeclaración (como en el same()método), que hace emitir un error en tiempo de compilación! ¿Por qué?

El compilador interpreta nullcomo una referencia nula a un Integer, aplica las reglas de autoboxing / unboxing para el operador condicional (como se describe en la Especificación del lenguaje Java, 15.25 ), y continúa felizmente. Esto generará un NullPointerExceptiontiempo de ejecución, que puede confirmar probándolo.

Creo que el compilador de Java interpreta true ? null : 0como una Integerexpresión, que se puede convertir implícitamente int, posiblemente dando NullPointerException.

Para el segundo caso, la expresión nulles del tipo nulo especial ver , por lo que el código return nullhace que el tipo no coincida.

En realidad, todo se explica en la Especificación del lenguaje Java .

El tipo de una expresión condicional se determina de la siguiente manera:

• Si el segundo y tercer operandos tienen el mismo tipo (que puede ser el tipo nulo), entonces ese es el tipo de la expresión condicional.

Por lo tanto, el "nulo" en su (true ? null : 0)obtiene un tipo int y luego se autoboxing a Integer.

Pruebe algo como esto para verificar esto (true ? null : null)y obtendrá el error del compilador.

En el caso de la ifdeclaración, la nullreferencia no se trata como una Integerreferencia porque no participa en una expresión que obliga a interpretarla como tal. Por lo tanto, el error puede detectarse fácilmente en tiempo de compilación porque es más claramente un error de tipo .

En cuanto al operador condicional, la Especificación del lenguaje Java §15.25 "Operador condicional ? :" responde esto muy bien en las reglas sobre cómo se aplica la conversión de tipo:

• Si el segundo y tercer operandos tienen el mismo tipo (que puede ser el tipo nulo), entonces ese es el tipo de la expresión condicional.
  
  No aplica porque nullno lo es int.

---

• Si uno de los operandos segundo y tercero es de tipo booleano y el tipo del otro es de tipo booleano, entonces el tipo de la expresión condicional es booleano.
  
  No aplica porque ni nulltampoco intes booleano Boolean.

---

• Si uno de los operandos segundo y tercero es del tipo nulo y el tipo del otro es un tipo de referencia, entonces el tipo de la expresión condicional es ese tipo de referencia.
  
  No se aplica porque nulles del tipo nulo, pero intno es un tipo de referencia.

---

• De lo contrario, si los operandos segundo y tercero tienen tipos que son convertibles (§5.1.8) a tipos numéricos, entonces hay varios casos: […]
  
  Aplica: nullse trata como convertible a un tipo numérico y se define en §5.1. 8 "Conversión de Unboxing" para lanzar a NullPointerException.

Lo primero a tener en cuenta es que los operadores ternarios de Java tienen un "tipo", y que esto es lo que el compilador determinará y considerará sin importar cuáles sean los tipos reales / reales del segundo o tercer parámetro. Dependiendo de varios factores, el tipo de operador ternario se determina de diferentes maneras, como se ilustra en la Especificación del lenguaje Java 15.26

En la pregunta anterior deberíamos considerar el último caso:

De lo contrario, el segundo y tercer operandos son de los tipos S1 y S2 respectivamente. Deje que T1 sea ​​el tipo que resulta de aplicar la conversión de boxeo a S1 , y que T2 sea ​​el tipo que resulta de aplicar la conversión de boxeo a S2 . El tipo de expresión condicional es el resultado de aplicar la conversión de captura (§5.1.10) a lub (T1, T2) (§15.12.2.7).

Este es, con mucho, el caso más complejo una vez que echa un vistazo a la aplicación de la conversión de captura (§5.1.10) y, sobre todo, en lub (T1, T2) .

En inglés simple y después de una simplificación extrema, podemos describir el proceso como el cálculo de la "Superclase menos común" (sí, piense en el MCM) del segundo y tercer parámetro. Esto nos dará el operador "tipo" ternario. Nuevamente, lo que acabo de decir es una simplificación extrema (considere las clases que implementan múltiples interfaces comunes).

Por ejemplo, si intenta lo siguiente:

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

Notarás que el tipo resultante de la expresión condicional se debe a java.util.Dateque es la "Superclase menos común" para el Timestamp/ Timepar.

Dado que nullse puede autoboxear a cualquier cosa, la "Superclase menos común" es la Integerclase y este será el tipo de retorno de la expresión condicional (operador ternario) anterior. El valor de retorno será entonces un puntero nulo de tipo Integery eso es lo que devolverá el operador ternario.

En tiempo de ejecución, cuando la máquina virtual de Java unboxes la Integeruna NullPointerExceptionse lanza. Esto sucede porque la JVM intenta invocar la función null.intValue(), donde nulles el resultado del autoboxing.

En mi opinión (y dado que mi opinión no está en la Especificación del lenguaje Java, muchas personas lo encontrarán mal de todos modos) el compilador hace un mal trabajo al evaluar la expresión en su pregunta. Dado que usted escribió, true ? param1 : param2el compilador debe determinar de inmediato que nullse devolverá el primer parámetro - y generará un error de compilación. Esto es algo similar a cuando escribe while(true){} etc...y el compilador se queja del código debajo del bucle y lo marca Unreachable Statements.

Su segundo caso es bastante sencillo y esta respuesta ya es demasiado larga ...;)

CORRECCIÓN:

Después de otro análisis, creo que me equivoqué al decir que un nullvalor se puede encuadrar / encuadrar automáticamente en cualquier cosa. Hablando de la clase Integer, el boxeo explícito consiste en invocar al new Integer(...)constructor o tal vez el Integer.valueOf(int i);(encontré esta versión en alguna parte). El primero arrojaría un NumberFormatException(y esto no sucede) mientras que el segundo simplemente no tendría sentido ya que un intno puede ser null...

En realidad, en el primer caso, la expresión se puede evaluar, ya que el compilador sabe que debe evaluarse como un Integer; sin embargo, en el segundo caso, el tipo del valor de retorno ( null) no se puede determinar, por lo que no se puede compilar. Si lo envía Integer, el código se compilará.

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
}

Qué tal esto:

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);

    }

}

La salida es verdadera, verdadera.

El color del eclipse codifica el 1 en la expresión condicional como autoboxed.

Supongo que el compilador está viendo el tipo de retorno de la expresión como Object.