javac 类路径顺序与 Oracle 文档相矛盾？

Question

在Sierra/Bates SCJP书第 797 页:

"java and javac [...] first look in the directories that contain the classes that come standard with Java SE. Then they look in the directories defined by classpaths"

Oracle documentation正在陈述相同的命令。

(我知道我不应该那样做，但是......)为了测试这个行为，我在目录中实现了 HashSet.java 和 Lol.java:C:\dev\cmdline\TestProject\sources\java\util

package java.util;
public class HashSet {}

和

package java.util;
import java.util.HashSet;
public class Lol {
    public static void main(String... x) {
        HashSet a = new HashSet();
        a.add("lol");
    }
}

执行时出现编译错误:C:\dev\cmdline\TestProject\sources>javac java/util/Lol.java

java\util\Lol.java:6: error: cannot find symbol a.add("lol"); ^ symbol: method add(String) location: variable a of type HashSet

...这意味着首先使用默认类路径(当前目录)。

那么，Oracle 文档有错吗？您将如何测试类路径顺序？

Answer 1

引用 Oracle 文档，SCJP 书中的陈述可能过于简单化了。 Oracle 文档明确区分了“Java 启动器”(java) 和 Java 编译器 javac。事实上，过程有些不同。

我将尝试提取相关部分来解释您所观察到的行为:

_{(From How Classes are Found : How Javac and JavaDoc Find Classes:)}

If a referenced class is defined in both a class file and source file, [...] javac uses class files, but automatically recompiles any class files it determines to be out of date. The rules for automatic recompilation are documented in the javac document for Windows or Solaris.

这些链接文档包含相应的小节(在两种情况下都是相同的)，我将在此处再次引用:

_{(From javac - Java programming language compiler : SEARCHING FOR TYPES:)}

When compiling a source file, the compiler often needs information about a type whose definition did not appear in the source files given on the command line. [...]

When the compiler needs type information, it looks for a source file or class file which defines the type. [...]

A successful type search may produce a class file, a source file, or both. If both are found, you can use the -Xprefer option to instruct the compiler which to use. If newer is given, the compiler will use the newer of the two files. If source is given, it will use the source file. The default is newer.

If a type search finds a source file for a required type, either by itself, or as a result of the setting for -Xprefer, the compiler will read the source file to get the information it needs. In addition, it will by default compile the source file as well. You can use the -implicit option to specify the behavior. If none is given, no class files will be generated for the source file. If class is given, class files will be generated for the source file.

总结一下:javac 编译器将为 java.util.HashSet 以及 找到您的源 文件class 来自 Bootstrap 类的文件。但默认情况下，它会编译源文件。

(有趣的是，似乎没有简单的方法可以说服他不要使用源代码作为输入:-implicit 选项只确定一个 .class 文件是否是生成的，但即使设置了-implicit:none，它仍将使用从源创建的类...)

您还可以使用 -verbose 选项来更详细地观察这个过程:

javac -verbose java/util/Lol.java

产生以下输出:

[parsing started RegularFileObject[java\util\Lol.java]]
[parsing completed 100ms]
[search path for source files: .]
[search path for class files: (A long list with rt.jar and related JARs)]
[loading RegularFileObject[.\java\util\HashSet.java]]
[parsing started RegularFileObject[.\java\util\HashSet.java]]
[parsing completed 0ms]
[loading ZipFileIndexFileObject[c:\jdk1.8.0\lib\ct.sym(META-INF/sym/rt.jar/java/lang/Object.class)]]
[loading ZipFileIndexFileObject[c:\jdk1.8.0\lib\ct.sym(META-INF/sym/rt.jar/java/lang/String.class)]]
[checking java.util.Lol]
[loading ZipFileIndexFileObject[c:\jdk1.8.0\lib\ct.sym(META-INF/sym/rt.jar/java/lang/AutoCloseable.class)]]
[loading ZipFileIndexFileObject[c:\jdk1.8.0\lib\ct.sym(META-INF/sym/rt.jar/java/lang/Byte.class)]]
[loading ZipFileIndexFileObject[c:\jdk1.8.0\lib\ct.sym(META-INF/sym/rt.jar/java/lang/Character.class)]]
[loading ZipFileIndexFileObject[c:\jdk1.8.0\lib\ct.sym(META-INF/sym/rt.jar/java/lang/Short.class)]]
[loading ZipFileIndexFileObject[c:\jdk1.8.0\lib\ct.sym(META-INF/sym/rt.jar/java/lang/Long.class)]]
[loading ZipFileIndexFileObject[c:\jdk1.8.0\lib\ct.sym(META-INF/sym/rt.jar/java/lang/Float.class)]]
[loading ZipFileIndexFileObject[c:\jdk1.8.0\lib\ct.sym(META-INF/sym/rt.jar/java/lang/Integer.class)]]
[loading ZipFileIndexFileObject[c:\jdk1.8.0\lib\ct.sym(META-INF/sym/rt.jar/java/lang/Double.class)]]
[loading ZipFileIndexFileObject[c:\jdk1.8.0\lib\ct.sym(META-INF/sym/rt.jar/java/lang/Boolean.class)]]
[loading ZipFileIndexFileObject[c:\jdk1.8.0\lib\ct.sym(META-INF/sym/rt.jar/java/lang/Void.class)]]
java\util\Lol.java:6: error: cannot find symbol
        a.add("lol");
         ^
  symbol:   method add(String)
  location: variable a of type HashSet
[checking java.util.HashSet]
[total 1072ms]
1 error

它甚至不尝试从引导 JAR 加载 HashSet` 类，而是直接引用您的源文件:

[loading RegularFileObject[.\java\util\HashSet.java]]

相比之下，当您省略自己的 HashSet 类时，您将看到预期的输出:

[parsing started RegularFileObject[java\util\Lol.java]]
[parsing completed 100ms]
[search path for source files: .]
[search path for class files: (A long list with rt.jar and related JARs) ]
[loading ZipFileIndexFileObject[c:\jdk1.8.0\lib\ct.sym(META-INF/sym/rt.jar/java/util/HashSet.class)]]
[loading ZipFileIndexFileObject[c:\jdk1.8.0\lib\ct.sym(META-INF/sym/rt.jar/java/lang/Object.class)]]
...

它从 rt.jar 中获取 HashSet 类。