Pourquoi est-int-Objet de comparaison valable dans Java 7, mais pas en Java 8?

Question

Le code suivant

private boolean compare(Object a, int b) {
    return a == b;
}

compile dans Java 7, mais il génère l'erreur suivante dans Java 8:

incomparable types: int et Objet

À la recherche à la question suivante:

La comparaison de l'Objet et int dans Java 7

Il semble que Java 6 et Java 8 ne laissez pas vous comparer int et Object, tandis que 7 ne. Est-il une documentation sur ce sujet?

Je suis intéressé par les connaissances de base qui en a informé de ces décisions. Il semble qu'ils étaient indécis ou quelque chose.

Je suis à l'aide d' IntelliJ IDEA 14.1.4 avec JDK 1.7.0.51.

Answer 1

Java 7 s'applique l'autoboxing à l'int.

 private boolean compare(java.lang.Object, int);
   Code:
      0: aload_1
      1: iload_2
      2: invokestatic  #2       // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
      5: if_acmpne     12
      8: iconst_1
      9: goto          13
     12: iconst_0
     13: ireturn

J'ai créé ce avec build 1.7.0_71-b14

EDIT:

Ce comportement a été reconnu et traité comme bug par Oracle:
JDK-8013357: Javac accepte erronée comparaison binaire des opérations

Pertinentes JLS section est 15.21. Javac semble considérer cela comme un référence de comparaison, mais une référence de comparaison n'est autorisée que lorsque Les DEUX opérandes sont des types référence.
...
Le type de règles pour les comparaisons binaires dans JLS Section 15.21 sera désormais correctement appliquée par javac. Depuis JDK5, javac a accepté certaines programmes avec l'Objet primitif de comparaisons qui sont mal tapé selon JLS 15.21. Ces comparaisons seront désormais correctement identifiés comme des erreurs de type.

Answer 2

Le JLS - Chapitre 15. Opérateurs d'égalité mentionne 3 == opérateurs: numérique, booléen et de référence. Aucun de l' == , les opérateurs peuvent se produire dans votre exemple, si nous concluons que la déclaration est illégal.

Voyons pourquoi l' == ne peut pas être appliquée dans votre exemple:

• 15.21.2. Boolean Opérateurs d'Égalité == et !=

  Nul besoin de vous préciser pourquoi il n'est pas pertinent..

• 15.21.3. Référence de l'Égalité des Opérateurs == et !=

  Si les opérandes d'un opérateur d'égalité sont à la fois de référence de type ou de type null, alors l'opération a fait l'objet d'égalité.

  C'est une erreur de compilation si il est impossible de convertir le type de l'opérande le type de l'autre par un casting de conversion (§5.5). Les valeurs d'exécution des deux opérandes serait nécessairement inégale.

• 15.21.1. L'Égalité numérique des Opérateurs == et !=

  Si les opérandes d'un opérateur d'égalité sont tous les deux de type numérique, ou l'un est de type numérique et l'autre est convertible (§5.1.8) de type numérique, binaire numérique de la promotion est effectuée sur les opérandes (§5.6.2).

Maintenant, supposons que c'est légal et que le compilateur a changé la ligne:

if (a == new Integer(b))

Qu'attendez-vous le résultat? La condition ne sera jamais^* évaluer à l' true, il est donc logique qu'il a été fixé dans Java 8.

Answer 3

Je ne pouvais pas obtenir un exemple pour compiler (fixation de bool → boolean) avec javac 1.7.0_75, ni avec javac 1.8.0_60. Je n'ai pas de JDK6, mais je ne pense pas qu'il devrait y ont travaillé. C'est peut-être plus tôt cjce incompatibilité, comme Axel conseils, ou d'un bug dans une autre version mineure de javac.

En tout cas, si ça marche, c'est en raison de l'autoboxing. Cela peut avoir été réduit en préparation pour Java 8, car les ruisseaux et l'autoboxing, ne pas mélanger trop bien.

Answer 4

Il ne devrait pas avoir compilé, selon JLS 7. int peut être comparé à boxed types numériques, c'est à dire Byte, Short, Character, Integer, Long, Float, Double. Mais c'est tout.

Et si la comparaison est entre int et de dire Float, Float sera décaissement de la première, de sorte que la comparaison entre float et int. Ça va faire aucun sens de le faire dans l'autre sens autour de boîte - int alors examiner l'identité de l' Integer (avec un Float pas moins).