Wyjątek NullPointerException dzięki automatycznemu bokserskiemu działaniu trójargumentowego operatora Java

Potknąłem się o naprawdę dziwnyNullPointerException inny dzień spowodowany nieoczekiwanym rzutem w operatorze trójskładnikowym. Biorąc pod uwagę tę (bezużyteczną przykładową) funkcję:

Integer getNumber() {
    return null;
}

Po kompilacji spodziewałem się, że następujące dwa segmenty kodu będą identyczne:

Integer number;
if (condition) {
    number = getNumber();
} else {
    number = 0;
}

vs.

Integer number = (condition) ? getNumber() : 0;

.

Okazuje się, jeślicondition jesttrue, theif-statement działa dobrze, podczas gdy trójskładnikowy opracja w drugim segmencie kodu rzuca aNullPointerException. Wygląda na to, że operacja trójskładnikowa postanowiła wpisać oba wyboryint przed automatycznym wstawieniem wyniku z powrotem doInteger!?! W rzeczywistości, jeśli wyraźnie rzucę0 doInteger, wyjątek zniknie. Innymi słowy:

Integer number = (condition) ? getNumber() : 0;

nie jest tym samym co:

Integer number = (condition) ? getNumber() : (Integer) 0;

.

Wydaje się więc, że istnieje różnica między kodem bajtowym między operatorem trójskładnikowym a odpowiednikiemif-else-statement (coś, czego się nie spodziewałem). Co rodzi trzy pytania: Dlaczego istnieje różnica? Czy jest to błąd w implementacji trójskładnikowej, czy istnieje powód rzucania typu? Biorąc pod uwagę różnicę, czy operacja trójskładnikowa jest bardziej lub mniej skuteczna niż odpowiednikif-statement (wiem, różnica nie może być ogromna, ale wciąż)?

questionAnswers(3)

yourAnswerToTheQuestion