NullPointerException durch Auto-Boxing-Verhalten des Java-Ternary-Operators

Ich stolperte über eine wirklich seltsameNullPointerException neulich verursacht durch eine unerwartete Typumwandlung im ternären Operator. In Anbetracht dieser (unnütz beispielhaften) Funktion:

Integer getNumber() {
    return null;
}

Ich habe erwartet, dass die folgenden beiden Codesegmente nach der Kompilierung exakt identisch sind:

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

gegen

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

.

Es stellt sich heraus, wenncondition isttrue, dasif-Anweisung funktioniert einwandfrei, während die ternäre Operation im zweiten Codesegment a auslöstNullPointerException. Es scheint, als ob die ternäre Operation beschlossen hat, beide Optionen zu tippenint bevor Sie das Ergebnis automatisch wieder in einInteger!?! In der Tat, wenn ich das explizit besetze0 zuInteger, die ausnahme geht weg. Mit anderen Worten:

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

ist nicht dasselbe wie:

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

.

Es scheint also einen Unterschied im Bytecode zwischen dem ternären Operator und einem Äquivalent zu gebenif-else-Statement (etwas, mit dem ich nicht gerechnet habe). Was drei Fragen aufwirft: Warum gibt es einen Unterschied? Ist dies ein Fehler in der ternären Implementierung oder gibt es einen Grund für die Typumwandlung? Wenn es einen Unterschied gibt, ist die ternäre Operation mehr oder weniger performant als eine äquivalenteif-Statement (Ich weiß, der Unterschied kann nicht groß sein, aber immer noch)?

Antworten auf die Frage(3)

Ihre Antwort auf die Frage