Java casting dans les interfaces

Quelqu'un peut-il m'expliquer comment le compilateur ne se plaint pas de la première coulée, mais ne se plaignent dans le deuxième?

interface I1 { }
interface I2 { }
class C1 implements I1 { }
class C2 implements I2 { }

public class Test{
     public static void main(){
        C1 o1 = new C1();
        C2 o2 = new C2();
        Integer o3 = new Integer(4);

        I2 x = (I2)o1; //compiler does not complain
        I2 y = (I2)o3; //compiler complains here !!
     }
}

Par l'exécution de cette, vous rencontrerez ClassCastException, qui est un RuntimeException.
vous avez tort
Où ai-je tort?
L'OP a dit que le compilateur se plaint suggérant à moi que vous n'obtenez pas une chance pour l'exécuter.
même s'il pouvait l'obtenir à compiler par la fixation de l'élément qui a eu une erreur de compilation, la ligne ci-dessus, il aurait provoqué une ClassCastException.
Vous avez tort parce que vous parlez de choses que vous ne devriez pas. L'eau est mouillée. Mais il est faux de parler de ce problème dans ce contexte. Ok? Évidemment, la question de savoir à ce sujet parce qu'il fait une expérience.
La raison pour laquelle je demande parce que je ne pouvais pas comprendre pourquoi le compilateur se comporte différemment dans ces deux cas. Maintenant, il fait sens. Merci!!
l'eau est humide ne fait pas de sens. L'eau est liquide. Il peut sembler évident pour beaucoup, mais on ne peut pas simplement supposer que cela est évident pour tout le monde. Plutôt, nous amener à l'évidence pour des précisions au lieu de le laisser glisser.

InformationsquelleAutor geo | 2013-04-24

145

Lorsque vous lancez o1 et o3 avec (I2), vous dire au compilateur que la classe de l'objet est en fait une sous-classe de son type déclaré, et que cette sous-classe implémente I2.

La Integer classe est final, donc o3 ne peut pas être une instance d'une sous-classe de Integer: le compilateur sait que vous mentez. C1 n'est cependant pas définitif, donc o1 pourrait être une instance d'un sous-type de C1 qui implémente I2.

Si vous faites C1 final, le compilateur va se plaindre de trop:
```
interface I1 { }
interface I2 { }
final class C1 implements I1 { }
class C2 implements I2 { }

public class Test{
     public static void main(){
        C1 o1 = new C1();
        C2 o2 = new C2();
        Integer o3 = new Integer(4);

        I2 y = (I2)o3; //compiler complains here !!
        I2 x = (I2)o1; //compiler complains too
     }
}
```
- "Integer est définitive, alors o3 comme aucune chance d'être de l'interface I2" C'est assez beaucoup de mal dans ce formulaire. Pas le sens, mais le phrasé.
- C'est vrai, j'ai édité ma réponse, c'est OK maintenant?
- Je n'étais pas à se plaindre de la faute de frappe, mais la formulation de la réponse. Si vous jetez un oeil ci-dessous, vous allez voir comment beaucoup plus claire Etienne phrasé de la même chose. La vôtre peut être misunderstandable, donc trompeur que vous n'avez pas mentionné (par exemple) que de la classe de Integer est définitive (ce qui est évident pour vous et moi, mais probablement pas pour tout le monde) et le "n'a aucune chance d'être une interface" la partie de ne pas y mettre trop d'informations; en fait, l'info en question est caché dans la deuxième phrase. On pourrait même penser qu' final classes ne peuvent pas mettre en œuvre des inferfaces qui n'est pas vrai.
- merci pour vos commentaires, j'ai édité ma réponse encore une fois. J'ai essayé d'ajouter plus d'explication, j'espère que ça ne fait pas ma réponse encore plus de confusion.
- Excellent! S'est avéré être une très belle explication 🙂
InformationsquelleAutor WilQu
35

Selon JLS chapitre 5

5.5.1. Type De Référence De La Coulée

Donné au moment de la compilation de référence de type S (source) et au moment de la compilation de référence de type T (cible), un casting de conversion existe de S à T si pas d'erreurs de compilation se produire en raison des règles suivantes.
Si T est un type d'interface:

Si S n'est pas une classe finale (§8.1.1), puis, s'il existe un supertype X de T, et un supertype Y de S tels que X et Y sont sensiblement distinctes type paramétré, et que les ratures de X et Y sont les mêmes, une erreur de compilation se produit.

Sinon, le casting est toujours légale au moment de la compilation (parce que même si S ne pas mettre en œuvre T, une sous-classe de la S pourrait).

Si S est une classe finale (§8.1.1), alors S doivent mettre en œuvre T, ou une erreur de compilation se produit.
- Il n'est pas une compétition...
- Je suppose que vous n'avez pas pris avec une pincée de sel! 🙂
InformationsquelleAutor maba
22

C'est parce que la classe Integer est définitive et C1 ne l'est pas. Ainsi, un objet Integer ne peut pas mettre en œuvre I2, tandis qu'une C1 de l'objet, s'il est une instance d'une sous-classe de la C1 qui implémente I2.
- le respect bro , vous êtes le héros méconnu de ce thread 😀
- +1 pour la concision.
InformationsquelleAutor Etienne Miret
15

Selon JLS 5.5.1 - Type de Référence de la coulée, la règle(s) s'appliquent:
- Si T est un type de classe, alors |S| <: |T| ou |T| <: |S|. Sinon, une erreur de compilation se produit.
  
  I2 y = (I2)o3; //compiler complains here !!
Dans ce cas, un Integer et I2 sont sans rapport avec en aucune manière, une erreur de compilation se produit. Aussi, parce que Integer est final, il n'y a aucun rapport entre Integer et I2.

I2 et I1 peuvent être liées en raison à la fois d'être un marqueur de l'interface (il n'y a pas de contrat).

Comme pour le code compilé, la règle suivante:
- Si S n'est pas une classe finale (§8.1.1), puis, s'il existe un supertype X de T, et un supertype Y de S tels que X et Y sont sensiblement distinctes type paramétré, et que les ratures de X et Y sont les mêmes, une erreur de compilation se produit.
S est o1 et T est I2.

Espère que cette aide.

InformationsquelleAutor Buhake Sindi

Vous devez vous connecter pour publier un commentaire.

5.5.1. Type De Référence De La Coulée