Formatter's behaviour depends on Gradle runtime's JDK version, not the toolchain's version

What happened?

With usage of Gradle toolchains, it's much more common for the Java version used for Gradle to substantially differ from the Java version used for compiling and running code.

What I observed is that formatting behaviour depended heavily on the JDK used to run Gradle. For example, if one runs Gradle with Java 11, the formatter will be unable to handle switch expressions, even though Gradle itself will happily compile the Java code, e.g.

19:17: error: illegal start of expression
com.palantir.javaformat.java.FormatterException: 19:17: error: illegal start of expression
        at com.palantir.javaformat.java.FormatterExceptions.fromJavacDiagnostics(FormatterExceptions.java:28)
        at com.palantir.javaformat.java.Formatter.parseJcCompilationUnit(Formatter.java:206)
        at com.palantir.javaformat.java.RemoveUnusedImports.parse(RemoveUnusedImports.java:214)
        at com.palantir.javaformat.java.RemoveUnusedImports.removeUnusedImports(RemoveUnusedImports.java:202)
        at com.palantir.javaformat.java.Formatter.formatSourceAndFixImports(Formatter.java:268)
        at com.palantir.javaformat.java.FormatterServiceImpl.formatSourceReflowStringsAndFixImports(FormatterServiceImpl.java:43)

but once JAVA_HOME is pointed at a Java version that supports switch expressions, formatting is successful.

What did you want to happen?

Preferred: Formatter respects the toolchain defined for the sourceset.
Acceptable: Formatter warns when the toolchain is incompatible.

Start by tracing Formatter.parseJcCompilationUnit and RemoveUnusedImports.parse, using the stack trace as the entry point. Investigate how formatting obtains the JDK when Gradle toolchains use another version. Done means formatting respects the sourceset toolchain, or clearly warns when that toolchain is incompatible.