A custom version of com.sun.tools.javac.api.JavacTool.
Review Request #4122 — Created July 25, 2016 and submitted
Zinc expects to use a class of that name as its java compiler.
If it fails to classload it directly, it'll use the one embedded
in the tools.jar of the JDK it's running on.
Therefore if we want to use some custom version of javac other
than the one in the JDK (say we want to run javac 9 on JDK 8),
then we only need to put that other javac on the classpath.
A future change will implement this, but to test that change
we need some alternative JavacTool that makes it easy to know
that it was invoked. This change introduces such a dummy JavacTool.
Those future tests can verify that the custom JavacTool was indeed
invoked by checking that the compilation attempt fails with
the error message "Pants caused Zinc to load a custom JavacTool".
The reason this is in a separate change than the tests that will
use it is so we can publish it from master, allowing the tests to
depend on it as a published tool.
Verified that this compiles, and can be used in the manner described.
CI passes: https://travis-ci.org/pantsbuild/pants/builds/147276262
Please link the relevant github issue to this one.
In the medium term, I'd prefer to fix our incorrect assumption about how zinc loads javac to actually use the javax.tools.JavaCompiler interface directly (if possible?). Ity and I are planning to contribute some patches upstream soon to address https://github.com/sbt/zinc/issues/144 , which will touch the code that loads JavaCompiler. If you have a suggestion about how to make the loading more generic, they'd be welcome on that issue.
Thanks for the reviews!