checkerframework-gradle-plugin icon indicating copy to clipboard operation
checkerframework-gradle-plugin copied to clipboard

JDK8 configuration applied to JDK11 compile tasks when Gradle itself is running under JDK8

Open kennknowles opened this issue 4 years ago • 2 comments

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

kennknowles avatar Jul 28 '20 18:07 kennknowles

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.

kennknowles avatar Jul 28 '20 18:07 kennknowles

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).

kelloggm avatar Aug 05 '20 22:08 kelloggm