better support forward Java versions

[robaho]

Expected Behavior

Gradle should be able to work out of the box with new Java releases, including the running of Gradle with the latest JDK version.

Gradle is a build and deployment tool and not being able to support the latest releases is big drawback.

See #25574. Jdk-21 was publically reviewable in Jul 2023, and generally available in September 2023. Based on comments in the cited issue, full support of JDK-21 won't be available until February of 2024.

The reason cited is the dependency on Kotlin, and the Kotlin DSL processor.

An interesting aspect is the IDE produced by the authors of the Kotlin DSL already supports JDK-21. It can be argued that not having Gradle support JDK-21 benefits the IDE developer and they have less motivation to fix related issues.

It is also questionable what the function of the "supported Java enum" is other than to delay support.

This issue is a feature request to split the delivery of Gradle into Groovy and Kotlin versions - to break the dependency on Kotlin release cycles.

Github projects list Kotlin as less than 2% and falling. The Kotlin codebase in Gradle is less than 10%.

Running a 100% Java program on a later JVM has always worked - at least as far as I can remember. This is not the case for Gradle.

Current Behavior (optional)

No response

Context

It appears other vscode extensions expect the Gradle version to be able to match the compiled class file versions, so when the other extensions and plugins (like Oracle's JLS) attempt to read the compiled class files they are unable to (because they are running too old a Java version).

[osiegmar]

Upvoted for better support forward Java versions.

But I'd like to see better support WITH Kotlin.

Maybe https://youtrack.jetbrains.com/issue/KT-58987/Use-some-available-JVM-target-if-theres-no-JvmTarget-for-the-inferred-toolchain-version helps?

[Griefed]

Upvoted for better support forward Java versions.

But I'd like to see better support WITH Kotlin.

Maybe https://youtrack.jetbrains.com/issue/KT-58987/Use-some-available-JVM-target-if-theres-no-JvmTarget-for-the-inferred-toolchain-version helps?

Agreed. Upvoted for better Java support.
With Kotlin, preferably. Even with 2% only on GitHub, not taking into account any other platform out there, that's a lot of code by a lot of people.

[simon-aira]

So do I understand things correctly then that the fix out in Kotlin 1.19.20 would already be solving this in the sense that Gradle 8.5 will run on Java 22, 23... etc?

This issue's proposed fix to split off Kotlin DSL in a separate package seems rather unlikely given that it was just assigned the default option for Gradle build scripts.

[ljacomet]

Thank you for your interest in Gradle

Gradle wants to have better forward support indeed. However what is proposed here will not happen.
What Kotlin did in 1.9.20 should help a lot, Gradle will be able to confirm this with Java 22.

As stated in our compatibility notes, Gradle also leverages its toolchain support to have better forward compatiblity. Running Gradle on the latest and compiling and testing with the latest do not need to be the same.

[robaho]

So it sounds like the best solution is to fork Gradle to have a Groovy only version for the Java community. Probably for the best anyway to limit dependencies.

Gradle has sort of become a one size kitchen sink monstrocity and this will help scale it back to its core functionality. Based on the compatibility notes, Gradle was already not being the best citizen in regards to forward compatibility.

I think this is essential as more frameworks/IDEs rely on Gradle build files as their SOT for their internal build systems. As the complexity of the build file grows so do these integrations in order to try and understand the gradle. The frequent changing of the syntax of these files doesn't help either.

The ecosystem and the vast majority of the gradle users need basic compile, test, jar, sign, and publish - along with easy to understand dependency management - gradle offers a lot more - seemingly unnecessary for most users. Then 'exit to shell' for really complex tasks that don't fit the simpler model.

Thanks for the input.

[ice1000]

So it sounds like the best solution is to fork Gradle to have a Groovy only version for the Java community. Probably for the best anyway to limit dependencies.

You will also have to make a fork of asm which has forward compatibility.

[ice1000]

See, e.g. #13481, #16857, #19283

[ice1000]

@robaho Honestly, I think making a tool huge as Gradle just to have good incremental compilation support is a bit too much. I was hoping there can be a simpler tool which does not require bytecode analysis to do Java building with support for plugins and downloading dependencies from repositories like maven central. I know @NekoCaffeine worked on a tool before, but it's based on their own fork of javac (which needs their own fork of IntelliJ IDEA to edit), and I was a bit too scared to use it.

With the new JPMS as a good potential replacement for maven pom, maybe a completely new ecosystem will evolve. I am seeking for ambitious people to do this together.

[robaho]

@ice1000 I think a more basic "gradle" that does incremental compile based on the timestamps/public api hashes (this can be done for most classes with a version agnostic class inspector) - would be easier to maintain going forward, especially from what I understand is the inability for gradle incremental to work well with annotated classes - which seems to be almost everything these days.

It is also somewhat suspect a lot of the claims regarding productivity improvements / cost savings based on build time. Almost always the developer is not blocked by this. For instance, even on Google cloud, Android builds routinely take hours. The developer is not just playing ping-pong while this happens. CPU time/cost is a real thing however, but I suspect the public api change check will catch the vast majority of these scenarios.

Large refactors will be a large build - but these are pretty rare.

I agree that the ecosystem needs something simpler.

[relgames]

Obviously Jetbrains had quite good PR to promote their language, but unfortunately they are not able to provide adequate support.

Not really sure why Gradle wants to keep promoting a product of another company given all those issues. Is Jetbrains the main sponsor of Gradle?

[robaho]

I think it is more that Android/Google relies on it. Although Google has their own build system Bazel. Maybe Android will move to that.