Avoid implicitly compiling sources from the classpath

[cpovirk]

You can see some internal discussion on CL 198652081, but in short:

• Truth depends on guava-gwt.
• The guava-gwt jar contains .java files.
• Truth has a test that uses Compile-Testing, and it compiles not just the file we give it but also (automatically and undesired by us) those .java files.
• This used to work, but because Truth uses guava-android but guava-gwt uses guava-jre, Maven puts guava-android on the classpath when guava-gwt needs guava-jre and its dependencies. So now the compilation fails.

We're going to work around this by:

• Making Truth pass -sourcepath '' to Compile-Testing.
• Adding an explicit dependency from guava-gwt to some dependencies that it uses directly but currently gets transitively through guava-jre.

But maybe Compile-Testing should be setting -sourcepath '' internally automatically? (Or maybe there's something else similar it should be doing; I've heard that all this is surprisingly complex.)

On the other hand, probably few people will be affected by this: They won't have .java files on their classpath, and even if they do, the files will compile fine because the dependencies will be there. Still, I wonder if they will see unexpected warnings or other output in some cases. (Maybe I've seen some reports of weird Compile-Testing behavior before in AutoValue or something? I'll see if I can dig anything up.) And presumably it's at least a little wasteful to compile files that we don't need.

[cpovirk]

Setting -sourcepath '' automatically internally breaks at least some Google-internal tests. Some look like they could be fixed by passing in all source files, rather than passing one and relying on javac to find the rest. The others were less clear to me. I believe they involved codegen, and I didn't dig further.

[tbroyer]

I don't think this is the problem you're hitting, but just in case, and to raise awareness of this weirdness, an empty source path apparently doesn't play well with module (module-info.java I presume) compilation with JDK9+. Gradle works around it by using a custom StandardJavaFileManager that doesn't expose any source file:

https://github.com/gradle/gradle/blob/v4.9.0/subprojects/language-java/src/main/java/org/gradle/api/internal/tasks/compile/JdkJavaCompiler.java#L61-L66

https://github.com/gradle/gradle/blob/v4.9.0/subprojects/language-java/src/main/java/org/gradle/api/internal/tasks/compile/reflect/SourcepathIgnoringInvocationHandler.java

[cpovirk]

Weird! I went looking and found gradle/gradle#2356 (and slightly related gradle/gradle#2330), albeit without a clear indication of whether this is an intentional javac behavior or a bug.

I agree that that's not likely to be the problem I'm hitting here, but it sounds likely to bite in the future, so thanks.

[cpovirk]

Error from a module not on the sourcepath is...

file should be on source path, or on patch path for module

...which I guess sounds intentional, if sad, given that I've read your https://blog.ltgt.net/most-build-tools-misuse-javac/

Searching for that leads to gradle/gradle#2302 (edit: also gradle/gradle#3035)