checkerframework-gradle-plugin
checkerframework-gradle-plugin copied to clipboard
JDK8 configuration applied to JDK11 compile tasks when Gradle itself is running under JDK8
Steps to reproduce on Mac with JAVA_HOME set to some JDK8 and JAVA11_HOME set to some JDK11
git clone --single-branch --branch checker-gradle-java11-trouble http://github.com/kennknowles/beam.git
cd beam
./gradlew \
-PcompileAndRunTestsWithJava11 \
-Pjava11home=$JAVA11_HOME
:sdks:java:extensions:sql:datacatalog:compileTestJava
In various environments, this fails because of the -Xbootclasspath/p
and --release
options.
Background: based on the gradle properties set there, we fork a separate Java 11 JVM to compile and run the tests: https://github.com/apache/beam/blob/02092dc36f3c8b2fa776c0513a1560d70924e8f7/buildSrc/src/main/groovy/org/apache/beam/gradle/BeamModulePlugin.groovy#L725
However, it is too late, because this line of the plugin has already run: https://github.com/kelloggm/checkerframework-gradle-plugin/blob/6739a86cf030ab35634a2b0ab6ac8859fe835473/src/main/groovy/org/checkerframework/gradle/plugin/CheckerFrameworkPlugin.groovy#L373
Actually I missed that needJdk8Jar
is based on the checkerframework version and we are at 3.5.0 so it should be false. So this must be due to needErrorProneJavac
.
This is tricky because I'm not sure how we'd detect that a different JVM is being substituted in the general case.
One option would be to check whether the compile task has forkOptions.javaHome
property set and then try to query that to figure out what Java version it is. That would only work if the compile task has finished being configured before the checker plugin runs, but it looks like that's probably the case in your particular scenario. I'm somewhat hesitant to do that based on how many problems we've had with the plugin's attempt to figure out the Checker Framework version based on the actual jar being used by Gradle and pick options accordingly, though.
In your scenario, though (which unless I misunderstand is different flavors of CI builds - that is, checking that everything works under both Java 8 and Java 11), skipping the CF on the Java 11 builds is the right choice, because the results will be identical to the Java 8 builds, since the CF is a source-level analysis (as you mentioned in apache/beam#12395).