2014-12-25 1 views

Antwort

9

Eigentlich in Java ist es absolut gültige ein artverwandte zum anderen zu werfen (auch wenn das Casting wenig Sinn macht). Sie erhalten einen Fehler während der Laufzeit, wenn die Typen nicht kompatibel sind.

Zum Beispiel:

public static void main(String[] args) { 
     String s = (String) new Object(); 
     System.out.println(s.intern()); 

    } 

Compiliert gut, aber gibt Exception in thread "main" java.lang.ClassCastException: java.lang.Object cannot be cast to java.lang.String at Sample.main(Sample.java:5) während der Laufzeit

+0

Hmm, wusste ich, dass es nicht. Also, sagst du selbst wenn Telefon Gerät nicht erweitert hat, Linie 1 würde immer noch an dem Compiler vorbeikommen? – user1529412

+0

@ user1529412 - Ja. Das ist richtig .. Überprüfen Sie meine Bearbeitung :) – TheLostMind

+1

Warum scheitert "(Number)" "? – August

5

Linie 1 wird eine Laufzeitausnahme werfen. Der Compiler überprüft nicht zur Kompilierzeit, ob die Besetzung erfolgreich durchgeführt werden kann. Deshalb ist es manchmal ratsam, dies zuerst mit dem Operator instanceof zu überprüfen.

In der Regel können Sie werfen immer eine Variable x vom Typ A an jeder Schnittstelle C, denn es kann eine Klasse vorhanden B extends A implements C oder eine Klasse B implements A, C

Das gleiche ist nicht wahr eine Variable x der Klasse zum Gießen A an jede Klasse D, da keine Unterklasse E extends A, D existieren kann, da eine Klasse möglicherweise nicht mehrere Klassen erweitert.

18

Der Grund der Compiler akzeptiert dies im JLS section 5.5.1 (relevanten Teil in fett) erklärt:

einen Compiler-S Referenztyp (source) und einen Compiler-Referenztyp T (target) Gegeben , eine Casting-Konvertierung besteht von S nach T, wenn aufgrund der folgenden Regeln keine Kompilierungsfehler auftreten.

Wenn S ein Klasse-Typ ist:

  • Wenn T ein Klassentyp ist, dann entweder | S | <: | T | oder | T | <: | S |. Andernfalls tritt ein Fehler bei der Kompilierung auf.

Weiterhin, wenn es einen übergeordneten Typ X von T vorhanden ist, und ein übergeordneter Typ Y von S, so daß sowohl X als auch Y beweisbar unterschiedlichen parametrisierten Typen (§4.5), und dass die Löschungen von X und Y sind die Gleichermaßen tritt ein Fehler bei der Kompilierung auf.

  • Wenn T ein Interface-Typ ist:

    • Wenn S nicht um eine endgültige Klasse (§8.1.1), dann, wenn ein übergeordneter Typ X von T vorhanden ist, und ein übergeordneter Typ Y von S, so dass sowohl X als auch Y nachweisbar unterschiedliche parametrisierte Typen sind, und dass die Löschungen von X und Y gleich sind, tritt ein Kompilierungsfehler auf.

      Andernfalls ist die Besetzung immer zur Kompilierzeit legal (denn auch wenn S T nicht implementiert, könnte eine Unterklasse von S).

In Ihrem Fall ein java.lang.ClassCastException wird seit Device nicht zu Talkable umgewandelt werden kann zur Laufzeit geworfen werden. Aber bis das Programm ausgeführt wird, kann der Compiler die Besetzung, weil es kann eine Unterklasse von Device sein, die Talkable implementiert.

3

Praktisch, in der ersten Zeile "teilt" der Code dem Compiler explizit mit, dass das Objekt auf der rechten Seite ein Objekt vom Typ auf der linken Seite ist (type casting). Dies gilt vor allen zwei Typen in Java in der Kompilierung, aber wenn Typen nichts zu tun haben, es geht um einen Laufzeitfehler sein (ein Exception wird geworfen werden).

Zeile zwei, was geschehen ist, ist gültig in Zeit und Laufzeit kompilieren, weil Phone der ist unabhängig von der Art sie erstreckt und/oder Geräte, so praktisch, Telefon ist ein Talkable (und ein Device).