Me tropecé con un muy extrañoNullPointerException el otro día causado por una conversión de tipo inesperada en el operador ternario. Dada esta función (ejemplar inútil):

Integer getNumber() {
    return null;
}

Esperaba que los siguientes dos segmentos de código fueran exactamente idénticos después de la compilación:

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

contra

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

.

Resulta, sicondition estrue, laif-la declaración funciona bien, mientras que la operación ternaria en el segundo segmento de código arroja unNullPointerException. Parece que la operación ternaria ha decidido fundir ambas opciones paraint antes de auto-boxear el resultado de nuevo en unaInteger!?! De hecho, si lanzo explícitamente el0 aInteger, la excepción desaparece. En otras palabras:

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

no es lo mismo que

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

.

Entonces, parece que hay una diferencia de byte-code entre el operador ternario y un equivalenteif-else-estudio (algo que no esperaba). Lo que plantea tres preguntas: ¿Por qué hay una diferencia? ¿Se trata de un error en la implementación ternaria o existe una razón para el tipo de conversión? Dado que hay una diferencia, ¿la operación ternaria es más o menos eficaz que una equivalente?if-Estado (lo sé, la diferencia no puede ser enorme, pero aún así).