Différences dans l’auto-unboxing entre vs Java 6 Java 7

Question

Salut j'ai noté une différence dans l'auto unboxing de comportement entre Java SE 6 et Java SE 7. Je me demande pourquoi, parce que je ne trouve pas de documentation des changements dans ce comportement entre ces deux versions.

Voici un exemple simple:

Object[] objs = new Object[2];
objs[0] = new Integer(5);
int myInt = (int)objs[0];

Cette compile bien avec javac de Java SE 7. Cependant, si je donne le compilateur de la "source de 1,6 argument de" j'obtiens une erreur sur la dernière ligne:

inconvertible types
found   : java.lang.Object
required: int

J'ai essayé de télécharger la version Java SE 6 pour compiler avec la version native 6 compilateur (sans aucune source d'option). Il accepte et donne la même erreur que ci-dessus.

Donc, ce qui donne? D'un peu plus de l'expérimentation, il semble que l'unboxing de la version 6 de Java ne peut unbox valeurs clairement (au moment de la compilation) est de la boite type. Par exemple, cela fonctionne dans les deux versions:

Integer[] objs = new Integer[2];
objs[0] = new Integer(5);
int myInt = (int)objs[0];

Il semble donc que, entre Java 6 et 7, l'unboxing de la fonctionnalité a été améliorée de sorte qu'il pourrait lancer et unbox types d'objets en un seul coup, sans le savoir (au moment de la compilation) que la valeur est de la bonne boxed de type. Cependant, la lecture à travers le Langage Java Spécification ou des billets de blog qui ont été écrits à l'époque de Java 7 est sorti, je ne vois aucun changement de cette chose, alors je me demandais ce que le changement est et ce que cette "fonctionnalité" est appelé?

Juste une curiosité: en Raison de la modification, il est possible de déclencher des "mauvais" unboxings:

Object[] objs = new Float[2];
objs[0] = new Float(5);
int myInt = (int)objs[0];

Cette compile bien, mais donne une ClassCastException au moment de l'exécution.

J'espère que quelqu'un peut m'aider avec une référence à la présente. Je vous remercie à l'avance.

Answer 1

Il ressemble à la langue dans la section 5.5 de la Coulée de Conversion de Java 7 JLS a été mis à jour en comparaison à la même section du Java 5/6 JLS, probablement afin de clarifier le permis de conversions.

Java 7 JLS dit

Une expression d'un type de référence peuvent subir casting de conversion d'un type primitif, sans erreur, par unboxing de conversion.

Java 5/6:

Une valeur d'un type de référence peut être converti en un type primitif par unboxing de conversion (§5.1.8).

La Java 7 JLS contient également un tableau (tableau 5.1) de permis de conversions (ce tableau n'est pas inclus dans le Java 5/6 JLS) de référence types de primitives. Cette explicitement les listes des moulages de l'Objet de primitives comme un rétrécissement de référence de la conversion avec l'unboxing.

La raison est expliquée dans cet e-mail:

Bottom line: Si la spec. permet (Objet)(int), il doit également être en permettant à (int)(Objet).

Answer 2

Vous avez raison, pour le dire plus simplement:

Object o = new Integer(1234);
int x = (int) o;

Cela fonctionne en Java 7, mais donne une erreur de compilation en Java 6 et ci-dessous. Étrangement, cette fonctionnalité n'est pas très documenté; par exemple, il n'est pas mentionné ici. On peut se demander si c'est une nouvelle fonctionnalité ou d'une correction de bug (ou un nouveau bug?), voir quelques infos et discussion. Le consensus semble pointer vers une ambiguïté dans l'original spec, qui a conduit à un légèrement incorrect/mise en œuvre incohérente sur Java 5/6, qui a été fixé à 7, car il est essentiel pour la mise en œuvre de la JSR 292 (Typées Dynamiquement les Langues).

Java l'autoboxing a maintenant quelques plus de pièges et de surprises. Par exemple

Object obj = new Integer(1234);
long x = (long)obj;

compiler, mais ne parviennent pas (avec ClassCastException) au moment de l'exécution. Cela, en revanche, va travailler:

long x = (long)(int)obj;