Opérateur ternaire vs. if Déclaration pour le retour nul de int

En Java, l'opérateur ternaire (?:) permet l'affectation de null à une variable de type int, même si int est un type de données primitif qui ne prend pas en charge les valeurs nulles. Considérez l'extrait de code suivant :

int temp() {
    return true ? null : 0;
}

Dans ce code, l'opérateur ternaire attribue null à la variable temp si true est la condition évaluée, sinon il attribue 0. Le compilateur autorise cette affectation sans émettre d'erreur. Cependant, lorsque la méthode est exécutée, elle lèvera une NullPointerException au moment de l'exécution car null n'est pas une valeur valide pour int.

Contrairement à l'opérateur ternaire, l'instruction if n'autorise pas de telles affectations nulles aux variables de types primitifs. Par exemple :

int same() {
    if (true) {
        return null;
    } else {
        return 0;
    }
}

Ce code générera une erreur de compilation avec le message "types incompatibles : null ne peut pas être converti en int." La raison de cette différence réside dans la façon dont le compilateur traite la valeur null.

Dans le cas de l'opérateur ternaire, le compilateur interprète le littéral nul comme une référence nulle à un Integer, la classe wrapper pour int. Cela est dû aux règles du compilateur pour l'autoboxing et unboxing : lors de la conversion d'un type primitif en un type d'objet, la machine virtuelle Java (JVM) encapsule automatiquement la valeur primitive dans le wrapper d'objet correspondant.

Puisque int est un type primitif, le compilateur tentera de déballer la valeur nulle renvoyée par l'opérateur ternaire, ce qui entraîne l'exception NullPointerException.

D'un autre côté, l'instruction if n'effectue pas ce processus de déballage et le littéral nul reste comme référence nulle à Object. Puisque le type de retour de la méthode same() est int, le compilateur ne peut pas convertir la référence nulle en int, d'où l'erreur de compilation.