Eu tropecei em um realmente estranhoNullPointerException no outro dia causado por um inesperado tipo de conversão no operador ternário. Dada esta função (inútil exemplar):

Integer getNumber() {
    return null;
}

Eu esperava que os dois segmentos de código a seguir fossem exatamente idênticos após a compilação:

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

vs.

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

.

Acontece que, secondition étrue, aif-instrução funciona bem, enquanto a operação ternária no segundo segmento de código lança umNullPointerException. Parece que a operação ternária decidiu digitar as duas opções paraint antes de auto-encaixotamento o resultado de volta em umInteger!?! Na verdade, se eu explicitamente lançar o0 paraInteger, a exceção vai embora. Em outras palavras:

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

não é o mesmo que:

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

.

Então, parece que há uma diferença de código de byte entre o operador ternário e um equivalenteif-else-atravamento (algo que eu não esperava). O que levanta três questões: por que há uma diferença? Isso é um bug na implementação do ternário ou há algum motivo para o tipo de conversão? Dado que existe uma diferença, a operação ternária é mais ou menos de desempenho que um equivalenteif(Eu sei, a diferença não pode ser enorme, mas ainda assim)?