What’s the Gradle company line on the conflicting ...
# general
c
What’s the Gradle company line on the conflicting status of Gradle and Groovy Java 17 support. My understanding is that Gradle claims Java 17 support, but that there are a number of Java 17 related bugs in Groovy 3.x that are fixed in 4.x but have not been backported. Currently I have a build that cannot run on Java 17, because a plugin is tickling a bug in Groovy 3.x (which is ‘provided’ by Gradle). Is it fair right now to claim Gradle Java 17 support?
a
Hi, there was no serious report that something doesn’t work well with Java 17 that I am aware of. What plugin is causing troubles that is provided by Gradle? Could you open an issue on Github with a reproducer?
Also do you maybe have links to Groovy bugs? Maybe we could ask them to backport them if there is no other option
c
It’s not a Gradle supplied plugin - it’s a third-party one. That said the discussion on this Groovy issue covers things pretty well: https://issues.apache.org/jira/browse/GROOVY-10145
The underlying issue in the grolifant plugin library: https://gitlab.com/ysb33rOrg/grolifant/-/issues/82
a
Huh, fun stuff. I guess currently the only way is to use
--add-opens
. I believe Groovy 4.0 for Gradle build scripts is still far away, since it will need to wait next major (8.0) and it needs some extra work and testing. It would be great if grolifant could fix that in their library if possible, but from the issue I see that is also not easy task to do
c
I don’t believe (although I’ll admit to not verifying) that
--add-opens
will work because the modules are dynamically generated. They don’t exist statically so cannot be opened in this manner.
l
Hey Chris, In a way, the Java version support of Gradle will always be constrained by the support of its underlying libraries. And in this case, Groovy + grolifant does not seem to work. But it works in a majority of use cases, so I do not think that is critical enough to demote the support announcement. After all 7.3 was released in November 2021 and this is the first report of incompatibility we get (from what I know)
What might be interesting is to see if we can get some of these bugs backported on the Groovy side if they are fixed in 4.x
c
😛 you know I’m just poking the bear with that statement. The fault here really lies with Groovy… it’s their bug. You guys putting pressure on Groovy would be helpful though. The latest traffic on their issue tracker indicated they were reluctant to commit to backporting.
a
I was playing a bit with that, and I believe Grolifant can fix it with this change:
Copy code
diff --git a/grolifant40/src/main/groovy/org/ysb33r/grolifant/api/v4/downloader/AbstractDistributionInstaller.groovy b/grolifant40/src/main/groovy/org/ysb33r/grolifant/api/v4/downloader/AbstractDistributionInstaller.groovy
index 742dfb8..2cb6b3c 100644
--- a/grolifant40/src/main/groovy/org/ysb33r/grolifant/api/v4/downloader/AbstractDistributionInstaller.groovy
+++ b/grolifant40/src/main/groovy/org/ysb33r/grolifant/api/v4/downloader/AbstractDistributionInstaller.groovy
@@ -220,9 +220,18 @@ abstract class AbstractDistributionInstaller implements DistributionInstaller {
             distributionName,
             projectOperations.gradleLogLevel
         )
-
-        this.artifactRootVerification = this.&verifyDistributionRoot as ArtifactRootVerification
-        this.artifactUnpacker = this.&unpack as ArtifactUnpacker
+        this.artifactRootVerification = new ArtifactRootVerification() {
+            @Override
+            File apply(File file) {
+                return AbstractDistributionInstaller.this.verifyDistributionRoot(file)
+            }
+        }
+        this.artifactUnpacker = new ArtifactUnpacker() {
+            @Override
+            void accept(File file, File file2) {
+                AbstractDistributionInstaller.this.unpack(file, file2)
+            }
+        }
         this.downloadRoot = projectOperations.map(projectOperations.gradleUserHomeDir, { File it ->
             new File(it, basePath)
         } as Transformer<File, File>)
So basically using normal classes instead of groovy method references that are converted to Closure. It also works if you want to workaround it in your build, example from the Grolifant issue:
Copy code
abstract class MyDistributionInstaller extends org.ysb33r.grolifant.api.v4.downloader.AbstractDistributionInstaller {
    MyDistributionInstaller(
            String distributionName,
            String basePath,
            org.ysb33r.grolifant.api.core.ProjectOperations projectOperations
    ) {
        super(distributionName, basePath, projectOperations)
        this.artifactRootVerification = new org.ysb33r.grolifant.api.v4.downloader.ArtifactRootVerification() {
            @Override
            File apply(File file) {
                return MyDistributionInstaller.this.verifyDistributionRoot(file)
            }
        }
        this.artifactUnpacker = new org.ysb33r.grolifant.api.v4.downloader.ArtifactUnpacker() {
            @Override
            void accept(File file, File file2) {
                MyDistributionInstaller.this.unpack(file, file2)
            }
        }
    }
}

tasks.register("doDownload") {
    doFirst {
        new MyDistributionInstaller("any", "download/", org.ysb33r.grolifant.api.core.ProjectOperations.create(project)) {
            @Override
            URI uriFromVersion(String version) {
                return URI.create("<https://github.com/mozilla/geckodriver/releases/download/v0.30.0/geckodriver-v0.30.0-linux64.tar.gz>")
            }
            @Override
            File verifyDistributionRoot(File distDir) {
                distDir
            }
        }.getDistributionRoot("any").get()
    }
}