Allow build to directly run under JDK 9 #25859
Conversation
ywelsch
requested review from
nik9000 and
rjernst
and removed request for
rjernst
| static void configureCompile(Project project) { | ||
| project.ext.compactProfile = 'compact3' | ||
| project.afterEvaluate { | ||
| // fail on all javac warnings |
There was a problem hiding this comment.
Can you remove this comment? I think it has drifted a long way from its home.
There was a problem hiding this comment.
I think I found the right place for it again a few lines below: 62a0717
| 'javax.xml.bind.util.ValidationEventCollector' | ||
| ] | ||
| } else { | ||
| thirdPartyAudit.excludes += [ |
There was a problem hiding this comment.
Might be worth a comment that these were added to the jre in 9 but we still need to include the jar because we expect to run in 8.
| options.forkOptions.memoryMaximumSize = "1g" | ||
| File gradleJavaHome = Jvm.current().javaHome | ||
| if (new File(project.javaHome).canonicalPath != gradleJavaHome.canonicalPath) { | ||
| options.fork = true |
There was a problem hiding this comment.
I get that we used to have to fork for java 9 all because gradle ran in java 8, but I think we can still fork if we want to. Do we no longer want to fork?
There was a problem hiding this comment.
As you said, this extra forking logic was introduced to deal with Java 9 compatibility issues in Gradle. It was overly broad, however, and we should not just fork processes for the fun of it. If, hopefully in the near future, we would require Gradle 4.1 as minimum version for running the build with Java 9, we could remove all this extra logic for distinguishing between the JVM that runs Gradle and the JVM that compiles / runs the tests..
There was a problem hiding this comment.
Sure. I'm fine with removing the fork. I think it is worth updating the commit message to make it clear that we no longer fork all the time, just if needed.
|
Thanks @nik9000 |
With Gradle 4.1 and newer JDK versions, we can finally invoke Gradle directly using a JDK9 JAVA_HOME without requiring a JDK8 to "bootstrap" the build. As the thirdPartyAudit task runs within the JVM that Gradle runs in, it needs to be adapted now to be JDK9 aware. This commit also changes the `JavaCompile` tasks to only fork if necessary (i.e. when Gradle's JVM and JAVA_HOME's JVM differ).
With Gradle 4.1 and newer JDK versions, we can finally invoke Gradle directly using a JDK9 JAVA_HOME without requiring a JDK8 to "bootstrap" the build. As the thirdPartyAudit task runs within the JVM that Gradle runs in, it needs to be adapted now to be JDK9 aware. This commit also changes the `JavaCompile` tasks to only fork if necessary (i.e. when Gradle's JVM and JAVA_HOME's JVM differ).
With Gradle 4.1 and newer JDK versions, we can finally invoke Gradle directly using a JDK9 JAVA_HOME without requiring a JDK8 to "bootstrap" the build. As the thirdPartyAudit task runs within the JVM that Gradle runs in, it needs to be adapted now to be JDK9 aware. This commit also changes the `JavaCompile` tasks to only fork if necessary (i.e. when Gradle's JVM and JAVA_HOME's JVM differ).
6 participants
With Gradle 4.1 and newer JDK versions, we can finally invoke Gradle directly using a JDK9
JAVA_HOMEwithout requiring a JDK8 to "bootstrap" the build. As thethirdPartyAudittask runs within the JVM that Gradle runs in, it needs to be adapted now to be JDK9 aware.I've tested this PR with Gradle 4.1-rc-1 and JDK9 b178.
Note that this also requires a small backport to the 5.x branch as the build checks out the 5.x branch and invokes a build of that version.