Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
kennknowles opened this issue Jul 28, 2020 · 2 comments

Comments

@kennknowles
Copy link

kennknowles commented Jul 28, 2020

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:

if (jvmVersion.isJava8() && javaSourceVersion.isJava8() && needJdk8Jar) {

@kennknowles
Copy link
Author

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 added a commit to kennknowles/beam that referenced this issue Jul 28, 2020
…ork-gradle-plugin#117

The plugin bases its configuration in part on what JVM Gradle runs during
configuration, which is JRE8 currently. Specifically it sets -Xbootclasspath/p
seemingly because:

 - the Gradle JVM used during configure is version 8
 - the source level is 8
 - Checker version is >= 3
@kelloggm
Copy link
Owner

kelloggm commented Aug 5, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants