Support alternate JavaCompilers (such as ECJ) in CompilationRule

[tbroyer]

ECJ expects all JavaFileObjects to be Files, so the rule no longer
uses Compilation.compile() but instead directly uses the JavaCompiler,
and processes a class rather than compiling a dummy (in-memory) source.

[doanduyhai]

It does not work for me when I use the Rule:

    @Rule
    public CompilationRule compilationRule = new CompilationRule(() -> new EclipseCompiler());

By debugging, I realized that in the Compilation class, we are still fetching the compiler from ToolProvider.getSystemJavaCompiler() and not from the CompilationRule ...

[tbroyer]

I think you're confusing two things: the CompilationRule and the Truth assertions. The CompilationRule doesn't change the behavior of the assertions.

[doanduyhai]

@tbroyer You're right, what I need is more something like:

 Truth.ASSERT.about(JavaSourceSubjectFactory.javaSource())
                .that(loadClass(XXX.class))
                .withCompiler(new EclipseCompiler())
                .withCompilerOptions("-nowarn", "-1.8")
                .processedWith(this)
                .compilesWithoutError();

For that, we need to add a new method withCompiler() to the JavaSourcesSubject class

I'll do a pull request for that

[gk5885]

Hey, @tbroyer. Sorry it took me quite so long to get back to you. The biggest problem with this p/r is that we can't use a file-based file manager (at least for the default). For most small projects, whether your tests access the disk or not is inconsequential, but for our test infrastructure it makes a very big difference in the aggregate.

I hate making special provisions just for how broken ecj is, but this might be a reasonable place to do a reflective check and fall back to their file manager iff we know it's eclipse.

Seem reasonable?

[tbroyer]

Hmm, not sure I follow… The tests won't reach the disk (and wrapping the file manager in an InMemoryJavaFileManager works the same, it just happens to be useless because we never actually use it, as the CompilationRule uses a processor that doesn't output anything).
Actually, the real deal-breaker with ECJ is the fact that we tried to compile a dummy class that isn't file-based (JavaFileObjects.forSourceLines("Dummy", "final class Dummy {}"); which leads to an java.lang.IllegalArgumentException: URI has an authority component when ECJ tries to create a java.io.File). Switching the rule to processing an already-compiled class (CompilationRule.class.getName() here) fixes the issue; but that would mean either changing the Compilation.compile() API with that new argument, or introducing a Compilation.process() method. I went with the option to copy only the necessary bits from Compilation.compile(), removing anything that wasn't useful for the CompilationRule (namely the Result and InMemoryJavaFileManager, and passing some nulls instead of empty sets).

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request) and all commit authors, but as best as we can tell these commits were authored by someone else. If that's the case, please add them to this pull request and have them confirm that they're okay with these commits being contributed to Google. If we're mistaken and you did author these commits, just reply here to confirm.

[tbroyer]

Rebased, and cherry-picked @doanduyhai's commit from #80 (effectively merging both PRs). PTAL.

[cpovirk]

I don't know the status of this, but for CLA purposes:

tbroyer appears to be the only author now: c09dd40 leads to https://github.com/google/compile-testing/commits?author=doanduyhai ("No commits found for 'doanduyhai'")