First of all, this test won’t work in Java 9 or later. Attempting to compile the String class will give this error:
java/lang/String.java:1: error: package exists in another module: java.base
package java.lang;
^
On Java 8, I get the behavior you see. Assuming that the tweaked String class is in the same source tree, the Main class compiles, but it gives an exception when you try to run it.
This appears to have been reported as bug 4929425. The resolution was this was a documentation bug, and they clarified the documentation for the javac command … though maybe not enough.
Anyhow, there is a difference, and it is a subtle one.
The java command simply searches in the following order:
- bootstrap classpath
- extension directories
- classpath
The javac command first searches the source directory. If it finds a source file there, it looks for a corresponding class file in the same location and (if necessary) compiles or recompiles it. If no source file is found, then it searches the classpaths for a class file as described above for java.
Note that it takes very careful reading of the javac manual entry to tease this out. It is easy to miss. (https://docs.oracle.com/javase/7/docs/technotes/tools/windows/javac.html#searching)
(IMO, they could make the manual page clearer. However, this inconsistency only makes a difference if you are attempting to override some class on the bootstrap classpath or in extension directory. And you are doing it in the wrong way. Basically, this is an edge case. The problem with clearly documenting obscure edge cases is that you can end up making the documentation more confusing for the normal case.)
4
solved order of classloader in java during compile time and run time