Unerwartete Reihenfolge der Fehler in Java-Kompilierung

Question

Beim Lösen einer Herausforderung online beobachtete ich das folgende Verhalten von Java, das ich ein wenig seltsam fand. Ich begann mit der Zusammenstellung eines Programms entlang nach folgendem Schema ab:

import java.io.*; 

class WeirdJava 
{ 
    public static void main (String[] args) 
    { 
     BufferedReader br = new BufferedReader(new InputStreamReader(System.in)); 
     String input = br.readLine(); 
     HashMap<Integer, Integer> map = new HashMap<Integer,Integer>(); 
     System.out.println("Weird Java"); 
    } 
} 

Beachten Sie, dass in dem obigen Programm gibt es zwei Fehler:

• Ich habe nicht behandelt Ausnahmen, die von BufferedReader geworfen werden könnten.
• Ich habe keine Standard-util-Bibliothek importiert, die HashMap enthält.

Nun, wenn ich versuche, das obige Programm zu kompilieren, der Java-Compiler gibt den Fehler, dass es nicht Symbol HashMap finden. Beachten Sie, dass die Deklaration mit HashMap nach BufferedReader erfolgt. Als nächstes füge ich hinzu, um das Programm die folgenden Import-Anweisung:

import java.util.HashMap; 

Wenn ich das Programm wieder zu kompilieren, diesmal der Compiler zeigt Fehler

nicht gemeldet Ausnahme IOException; müssen gefangen oder deklariert werden zu geworfen

Meine Fragen:

1. Warum ist dieser Fehler nicht in der vorherigen Kompilation Versuch geworfen?
2. Die Reihenfolge, in der Kompilierungsfehler auftreten, scheint nicht natürlich zu sein. Was sind die Compiler Design-Prinzipien, die während dieser Routine ins Spiel kommen?

Answer 1

Es ist einfach die Reihenfolge, in der Quelle vom Compiler überprüft wird. Der Compiler prüft insbesondere auf Importe und löst sie auf, bevor er nach Code sucht, der Methoden aufruft, die geprüfte Ausnahmen auslösen können.

Wenn Sie javac mit -verbose laufen, werden Sie feststellen, dass die Compiler lädt Klassen importiert, in diesem Fall BufferedReader und InputStreamReader, dann lädt er die öffentliche API-Klassen wie Object und String:

[loading ZipFileIndexFileObject[C:\Dev\Java\jdk1.7.0_75\lib\ct.sym(META-INF/sym/rt.jar/java/io/BufferedReader.class)]] 
[loading ZipFileIndexFileObject[C:\Dev\Java\jdk1.7.0_75\lib\ct.sym(META-INF/sym/rt.jar/java/io/InputStreamReader.class)] 
]  
[loading ZipFileIndexFileObject[C:\Dev\Java\jdk1.7.0_75\lib\ct.sym(META-INF/sym/rt.jar/java/lang/Object.class)]] 
[loading ZipFileIndexFileObject[C:\Dev\Java\jdk1.7.0_75\lib\ct.sym(META-INF/sym/rt.jar/java/lang/String.class)]] 
[checking test.Test] 
[loading ZipFileIndexFileObject[C:\Dev\Java\jdk1.7.0_75\lib\ct.sym(META-INF/sym/rt.jar/java/lang/AutoCloseable.class)]] 
[loading ZipFileIndexFileObject[C:\Dev\Java\jdk1.7.0_75\lib\ct.sym(META-INF/sym/rt.jar/java/lang/System.class)]] 
[loading ZipFileIndexFileObject[C:\Dev\Java\jdk1.7.0_75\lib\ct.sym(META-INF/sym/rt.jar/java/io/InputStream.class)]] 
[loading ZipFileIndexFileObject[C:\Dev\Java\jdk1.7.0_75\lib\ct.sym(META-INF/sym/rt.jar/java/io/Reader.class)]] 
Test.java:11: error: cannot find symbol 
    HashMap<Integer, Integer> map = new HashMap<Integer,Integer>(); 

Mit einem Blick Bei der Übersicht in ist das Laden der verwendeten Klassen selbst Teil der ersten Phasenkompilierung namens "Parse and Enter":

Jeder Baum ist bestanden ed auf Enter, die Symbole für alle Definitionen in die Symbole eingibt. Dies muss vor der Analyse von Bäumen geschehen, die auf diese Symbole verweisen können. Die Ausgabe dieser Phase ist eine Aufgabenliste, die Bäume enthält, die analysiert werden müssen und die Klassendateien generiert haben.