java編譯器如何解析非導入的名稱

Question

考慮我在包foo.bar java編譯單元中使用類型X ，並且X未在編譯單元本身中定義，也不直接導入。 java編譯器如何有效地解析X ？ X可以存在一些可能性：

1. X可能通過星形導入ab*導入
2. X可能與編譯單元位於同一個包中
3. X可能是一種語言類型，即駐留在java.lang

我看到的問題尤其是（2.）。 由於X可能是包私有類型，因此甚至不需要X駐留在名為X.java的編譯單元中。 因此，編譯器必須查看類路徑的所有條目並搜索包foo.bar任何類，然后必須讀取包foo.bar 每個類以檢查是否包含X

這聽起來非常昂貴。 特別是當我只編譯一個文件時，編譯器必須只讀取幾十個類文件才能找到一個類型X 如果我使用大量的星型導入，則必須對很多類型重復此過程（當然，類文件不會被讀取兩次）。

因此，建議從同一個包中導入類型以加快編譯過程嗎？ 或者是否有更快的方法來解析我無法找到的無類型X ？

Answer 1

這聽起來非常昂貴。

如果編譯器這樣做，那將是昂貴的。

但實際發生的是它構建了一個內存中的數據結構，其中包含類路徑，bootclasspath和sourcepath中的所有類名，並將其用於javac運行中編譯的所有類中的所有類名解析。

因此，建議從同一個包中導入類型以加快編譯過程嗎？ 或者是否有更快的方法來解析我無法找到的無類型X？

不，不。 它幾乎沒有任何區別。 此外，如果您使用編譯器如何設計使用它，這不太可能是一個重大的瓶頸。

最好以提供最可讀和最可靠代碼的方式進行導入。

Answer 2

因此，編譯器必須查看類路徑的所有條目並搜索包foo.bar中的任何類

這只是Class.forName() 。

然后它必須讀取包foo.bar中的每個類來檢查是否包含X.

我不知道這意味着什么。

在通過Class.forName(),查找.class文件之后Class.forName(),它必須通過相應的名稱new File(...).exists()當前包中的源路徑 ，該文件只是new File(...).exists()等。

我不相信它會通過該名稱查找每個文件中的非公共類：您必須嘗試它。 如果確實如此，那確實是一個昂貴的步驟，但我不相信它已被采納。