Renvoyer null comme un int autorisé avec l'opérateur ternaire mais pas l'instruction if

Examinons le code Java simple dans l'extrait de code suivant:

public class Main {

    private int temp() {
        return true ? null : 0;
        // No compiler error - the compiler allows a return value of null
        // in a method signature that returns an int.
    }

    private int same() {
        if (true) {
            return null;
            // The same is not possible with if,
            // and causes a compile-time error - incompatible types.
        } else {
            return 0;
        }
    }

    public static void main(String[] args) {
        Main m = new Main();
        System.out.println(m.temp());
        System.out.println(m.same());
    }
}

Dans ce code Java le plus simple, la temp()méthode n'émet aucune erreur du compilateur même si le type de retour de la fonction est int, et nous essayons de renvoyer la valeur null(via l'instruction return true ? null : 0;). Une fois compilé, cela provoque évidemment l'exception d'exécution NullPointerException.

Cependant, il semble que la même chose ne va pas si nous représentons l'opérateur ternaire avec une ifinstruction (comme dans la same()méthode), ce qui génère une erreur de compilation! Pourquoi?

Le compilateur interprète nullcomme une référence nulle à an Integer, applique les règles de mise en boîte automatique / unboxing pour l'opérateur conditionnel (comme décrit dans la spécification du langage Java, 15.25 ), et avance avec bonheur. Cela générera un NullPointerExceptionau moment de l'exécution, que vous pouvez confirmer en l'essayant.

Je pense que le compilateur Java interprète true ? null : 0comme une Integerexpression, qui peut être implicitement convertie en int, éventuellement en donnant NullPointerException.

Pour le second cas, l'expression nullest du type spécial nul , voir , donc le code return nullcrée une incompatibilité de type.

En fait, tout est expliqué dans la spécification du langage Java .

Le type d'une expression conditionnelle est déterminé comme suit:

• Si les deuxième et troisième opérandes ont le même type (qui peut être le type nul), alors c'est le type de l'expression conditionnelle.

Par conséquent, le "null" dans votre (true ? null : 0)obtient un type int, puis est automatiquement converti en Integer.

Essayez quelque chose comme ceci pour vérifier cela (true ? null : null)et vous obtiendrez l'erreur du compilateur.

Dans le cas de l' ifinstruction, la nullréférence n'est pas traitée comme une Integerréférence car elle ne participe pas à une expression qui la force à être interprétée comme telle. Par conséquent, l'erreur peut être facilement détectée au moment de la compilation car il s'agit plus clairement d'une erreur de type .

En ce qui concerne l'opérateur conditionnel, la spécification du langage Java §15.25 «Conditional Operator ? :» répond bien à cela dans les règles d'application de la conversion de type:

• Si les deuxième et troisième opérandes ont le même type (qui peut être le type nul), alors c'est le type de l'expression conditionnelle.
  
  Ne s'applique pas parce que nullnon int.

---

• Si l'un des deuxième et troisième opérandes est de type booléen et le type de l'autre est de type booléen, alors le type de l'expression conditionnelle est booléen.
  
  Ne s'applique pas parce que ni nullni intn'est booleanni Boolean.

---

• Si l'un des deuxième et troisième opérandes est de type nul et que le type de l'autre est un type référence, le type de l'expression conditionnelle est ce type référence.
  
  Ne s'applique pas car il nullest de type nul, mais intn'est pas un type référence.

---

• Sinon, si les deuxième et troisième opérandes ont des types convertibles (§5.1.8) en types numériques, alors il y a plusieurs cas: […]
  
  S'applique: nullest traité comme convertible en type numérique, et est défini au §5.1. 8 «Unboxing Conversion» pour lancer a NullPointerException.

La première chose à garder à l'esprit est que les opérateurs ternaires Java ont un "type", et que c'est ce que le compilateur déterminera et considérera quels que soient les types réels / réels du deuxième ou du troisième paramètre. En fonction de plusieurs facteurs, le type d'opérateur ternaire est déterminé de différentes manières, comme illustré dans la spécification du langage Java 15.26

Dans la question ci-dessus, nous devrions considérer le dernier cas:

Sinon, les deuxième et troisième opérandes sont respectivement de types S1 et S2 . Soit T1 le type qui résulte de l'application de la conversion de boxe à S1 , et soit T2 le type qui résulte de l'application de la conversion de boxe à S2 . Le type de l'expression conditionnelle est le résultat de l'application de la conversion de capture (§5.1.10) en lub (T1, T2) (§15.12.2.7).

C'est de loin le cas le plus complexe une fois que vous regardez l' application de la conversion de capture (§5.1.10) et surtout à lub (T1, T2) .

En anglais simple et après une simplification extrême, nous pouvons décrire le processus comme le calcul de la "Superclasse la moins commune" (oui, pensez au LCM) des deuxième et troisième paramètres. Cela nous donnera l'opérateur ternaire "type". Encore une fois, ce que je viens de dire est une simplification extrême (considérez les classes qui implémentent plusieurs interfaces communes).

Par exemple, si vous essayez ce qui suit:

long millis = System.currentTimeMillis();
return(true ? new java.sql.Timestamp(millis) : new java.sql.Time(millis));

Vous remarquerez que le type résultant de l'expression conditionnelle est java.util.Datepuisqu'il s'agit de la "Superclasse la moins commune" pour la paire Timestamp/ Time.

Puisqu'il nullpeut être autoboxé à n'importe quoi, la "Superclasse la moins commune" est la Integerclasse et ce sera le type de retour de l'expression conditionnelle (opérateur ternaire) ci-dessus. La valeur de retour sera alors un pointeur nul de type Integeret c'est ce qui sera retourné par l'opérateur ternaire.

Au moment de l'exécution, lorsque la machine virtuelle Java déballe, le Integera NullPointerExceptionest lancé. Cela se produit car la machine virtuelle Java tente d'appeler la fonction null.intValue(), où nullest le résultat de la détection automatique.

À mon avis (et comme mon avis n'est pas dans la spécification du langage Java, beaucoup de gens trouveront cela faux de toute façon), le compilateur fait un mauvais travail en évaluant l'expression dans votre question. Étant donné que vous avez écrit, true ? param1 : param2le compilateur doit déterminer tout de suite que le premier paramètre - null- sera renvoyé et il doit générer une erreur de compilation. C'est un peu similaire à lorsque vous écrivez while(true){} etc...et que le compilateur se plaint du code sous la boucle et le marque avec Unreachable Statements.

Votre deuxième cas est assez simple et cette réponse est déjà trop longue ...;)

CORRECTION:

Après une autre analyse, je crois que j'avais tort de dire qu'une nullvaleur peut être encadrée / auto-indexée sur n'importe quoi. En parlant de la classe Integer, la boxe explicite consiste à invoquer le new Integer(...)constructeur ou peut-être le Integer.valueOf(int i);(j'ai trouvé cette version quelque part). Le premier lancerait un NumberFormatException(et cela n'arrive pas) tandis que le second n'aurait tout simplement pas de sens car un intne peut pas être null...

En fait, dans le premier cas, l'expression peut être évaluée, puisque le compilateur sait, qu'elle doit être évaluée comme un Integer, mais dans le second cas, le type de la valeur de retour ( null) ne peut pas être déterminé, donc il ne peut pas être compilé. Si vous le convertissez en Integer, le code sera compilé.

private int temp() {

    if (true) {
        Integer x = null;
        return x;// since that is fine because of unboxing then the returned value could be null
        //in other words I can say x could be null or new Integer(intValue) or a intValue
    }

    return (true ? null : 0);  //this will be prefectly legal null would be refrence to Integer. The concept is one the returned
    //value can be Integer 
    // then null is accepted to be a variable (-refrence variable-) of Integer
}

Que dis-tu de ça:

public class ConditionalExpressionType {

    public static void main(String[] args) {

        String s = "";
        s += (true ? 1 : "") instanceof Integer;
        System.out.println(s);

        String t = "";
        t += (!true ? 1 : "") instanceof String;
        System.out.println(t);

    }

}

La sortie est vraie, vraie.

La couleur Eclipse code le 1 dans l'expression conditionnelle comme une boîte automatique.

Je suppose que le compilateur voit le type de retour de l'expression comme Object.