Restituisce null come int consentito con l'operatore ternario ma non se istruzione

Diamo un'occhiata al semplice codice Java nel seguente frammento:

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

In questo codice Java più semplice, il temp()metodo non genera alcun errore del compilatore anche se è il tipo restituito della funzione inte stiamo provando a restituire il valore null(tramite l'istruzione return true ? null : 0;). Quando compilato, questo ovviamente causa l'eccezione di runtime NullPointerException.

Tuttavia, sembra che la stessa cosa è sbagliato se noi rappresentiamo l'operatore ternario con una ifdichiarazione (come nel same()metodo), che fa emettere un errore di compilazione! Perché?

Il compilatore interpreta nullcome riferimento null a un Integer, applica le regole di autoboxing / unboxing per l'operatore condizionale (come descritto in Java Language Specification, 15.25 ) e si sposta felicemente su. Questo genererà un NullPointerExceptiontempo di esecuzione, che puoi confermare provandolo.

Penso che il compilatore Java interpreti true ? null : 0come Integerun'espressione, che può essere implicitamente convertita in int, possibilmente dando NullPointerException.

Per il secondo caso, l'espressione nullè di speciale tipo nullo veda , per cui il codice return nullrende tipo non corrispondente.

In realtà, è tutto spiegato nelle specifiche del linguaggio Java .

Il tipo di un'espressione condizionale è determinato come segue:

• Se il secondo e il terzo operando hanno lo stesso tipo (che può essere il tipo null), questo è il tipo dell'espressione condizionale.

Pertanto il "null" nel tuo (true ? null : 0)ottiene un tipo int e quindi viene autoboxato su Integer.

Prova qualcosa del genere per verificarlo (true ? null : null)e otterrai l'errore del compilatore.

Nel caso della ifdichiarazione, il nullriferimento non viene trattato come Integerriferimento perché non partecipa a un'espressione che lo costringe ad essere interpretato come tale. Pertanto, l'errore può essere facilmente individuato in fase di compilazione perché è più chiaramente un tipo errore di .

Per quanto riguarda l'operatore condizionale, la specifica del linguaggio Java §15.25 "Operatore condizionale ? :" risponde bene alle regole per l'applicazione della conversione del tipo:

• Se il secondo e il terzo operando hanno lo stesso tipo (che può essere il tipo null), questo è il tipo dell'espressione condizionale.
  
  Non si applica perché nullnon lo è int.

---

• Se uno dei secondi e terzi operandi è di tipo booleano e il tipo dell'altro è di tipo booleano, il tipo dell'espressione condizionale è booleano.
  
  Non si applica perché né nullné intè booleanné Boolean.

---

• Se uno dei secondi e terzi operandi è di tipo null e il tipo di altro è un tipo di riferimento, il tipo dell'espressione condizionale è quel tipo di riferimento.
  
  Non si applica perché nullè di tipo null, ma intnon è un tipo di riferimento.

---

• Altrimenti, se il secondo e il terzo operando hanno tipi convertibili (§5.1.8) in tipi numerici, allora ci sono diversi casi: […]
  
  Si applica: nullè trattato come convertibile in un tipo numerico ed è definito in §5.1. 8 "Conversione di Unboxing" per lanciare a NullPointerException.

La prima cosa da tenere a mente è che gli operatori ternari Java hanno un "tipo" e che questo è ciò che il compilatore determinerà e considererà indipendentemente dai tipi reali / reali del secondo o terzo parametro. A seconda di diversi fattori, il tipo di operatore ternario viene determinato in diversi modi, come illustrato nella specifica del linguaggio Java 15.26

Nella domanda sopra dovremmo considerare l'ultimo caso:

Altrimenti, il secondo e il terzo operando sono rispettivamente di tipo S1 e S2 . Sia T1 il tipo risultante dall'applicazione della conversione del pugilato a S1 e T2 sia il tipo risultante dall'applicazione della conversione del pugilato a S2 . Il tipo dell'espressione condizionale è il risultato dell'applicazione della conversione della cattura (§5.1.10) in lub (T1, T2) (§15.12.2.7).

Questo è di gran lunga il caso più complesso dopo aver dato un'occhiata all'applicazione della conversione di cattura (§5.1.10) e soprattutto a lub (T1, T2) .

In parole povere e dopo un'estrema semplificazione possiamo descrivere il processo come il calcolo della "Minima Superclasse Comune" (sì, pensa alla LCM) del secondo e terzo parametro. Questo ci darà l'operatore "tipo" ternario. Ancora una volta, ciò che ho appena detto è un'estrema semplificazione (considera le classi che implementano più interfacce comuni).

Ad esempio, se provi quanto segue:

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

Noterai che il tipo risultante dell'espressione condizionale è java.util.Datedato che è la "Superclass meno comune" per Timestamp/Time coppia .

Poiché nullpuò essere autoboxato su qualsiasi cosa, la "Superclass comune minima" è la Integerclasse e questo sarà il tipo restituito dell'espressione condizionale (operatore ternario) sopra. Il valore restituito sarà quindi un puntatore null di tipoInteger e questo è ciò che verrà restituito dall'operatore ternario.

In fase di esecuzione, quando la Java Virtual Machine unboxes l' Integeruna NullPointerExceptionè gettato. Ciò accade perché JVM tenta di richiamare la funzione null.intValue(), dove nullè il risultato del box automatico.

Secondo me (e poiché la mia opinione non è nella specifica del linguaggio Java, molte persone lo troveranno comunque sbagliato) il compilatore fa un pessimo lavoro nel valutare l'espressione nella tua domanda. Dato che hai scritto true ? param1 : param2il compilatore dovrebbe determinare immediatamente che il primo parametro - null- verrà restituito e dovrebbe generare un errore del compilatore. Questo è in qualche modo simile a quando scrivi while(true){} etc...e il compilatore si lamenta del codice sotto il ciclo e lo contrassegna Unreachable Statements.

Il tuo secondo caso è piuttosto semplice e questa risposta è già troppo lunga ...;)

CORREZIONE:

Dopo un'altra analisi, credo di aver sbagliato a dire che un nullvalore può essere inscatolato / autoboxato su qualsiasi cosa. Parlando della classe Integer, il boxing esplicito consiste nell'invocare il new Integer(...)costruttore o forse il Integer.valueOf(int i);(ho trovato questa versione da qualche parte). Il primo lancerebbe un NumberFormatException(e questo non accade) mentre il secondo non avrebbe senso dal momento che un intnon può essere null...

In realtà, nel primo caso l'espressione può essere valutata, poiché il compilatore lo sa, che deve essere valutata come una Integer, tuttavia nel secondo caso il tipo del valore restituito ( null) non può essere determinato, quindi non può essere compilato. Se Integerlo esegui, il codice verrà compilato.

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
}

Cosa ne pensi di questo:

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

    }

}

L'output è vero, vero.

Il colore Eclipse codifica il 1 nell'espressione condizionale come autobox.

La mia ipotesi è che il compilatore sta vedendo il tipo restituito dell'espressione come Object.