is gradle 9 do out this month?

My wild guess is, that this is quite unlikely. There was not even a first RC release. And the RC1 milestone has 149 open an 9 closed issues.

huh, so gradle 8 is going to go on for longer than most gradle releases, aight

The provider-migration is probably a much larger major task than stuff in previous releases, so yes, it probably needs significantly longer to be finished.

Any reason why you need Gradle 9 already?

We want provideeeeers everwheeeere 😄

Need? In addition to what vampire said according to what I read Gradle 9 is going to require Java 17

Which is a bad thing, but yeah 😄

I don;t think this will be fixed yet - I need to ask - but when using

filter

in Copy/Sync, the Ant filters are no lazy-evaluated which is a pain.

It's a good thing. I fundamentally disagree with that!

I don't think JDK17 is going to be that big an impact, because it is now easy to use toolchains to compile for older version of Java anyway.

I sincerely hope that the DCL isn't going to prevent Gradle 9 from happening

It is not unsupported. Java 8 has extended support until 2030 at least. And I have a build that I will not be able to update, as it builds a JavaCard applet and for that it has to use source- and target-version 6 which only works up until Java 11. Well, unless I majorly refactor that to somehow use separate process for that if possible or something like that, but it might not be possible as it would require changing the javacard plugin, ...

I don't count extended support 😜 If enterprises are paying for extended support for Java 8 then they can pay Gradle Inc for extended support for Java 8

We support 15+ OSS Gradle plugins, so we write code for maximum compatibility. That is why most of our plugins still support running on JDK8 as far as possible.

So I assume we'll be getting 8.13?

Yes, current latest release is

v8.13.0-M2

Yeah my plugins require Java 11 because I refused to not use the var keyword. I would like to move forward though; or at least not feel bad about not supporting Java 8

var

should only mean source language 11+, not necessarily target 11+

> I do think that it would not be unreasonable, for Gradle to offer a program like Oracle does for supporting versions longer with paid tiers I believe that does exist, it is just not publicly advertised. I think Gradle does have some support contracts with certain enterprises.

You're right but I don't think I figured out how to do that and I don't have time to look at it this exact second. I think when I tried to make that work I was unsuccessful for some reason. Might not even have been a Java problem but a intelliJ problem

2025 and people still do not know how OpenJDK maintenance works? https://medium.com/@javachampions/java-is-still-free-3-0-0-ocrt-2021-bca75c88d23b Red Hat leads maintenance for OpenJDK 8 until at least November 2026 (and OpenJDK 11 until at least October 2027). Many (most?) OpenJDK vendors will continue to provide OpenJDK builds until that date, that includes Red Hat of course (shorter timeframe for OpenJDK 11 though, already EOL), but also Adoptium's Eclipse Temurin and Azul's Zulu, and then they'll possibly provide paid support for an extended period.

@Vampire

I will not be able to update, as it builds a JavaCard applet and for that it has to use source- and target-version 6 which only works up until Java 11.

Can't you use the toolchain to build with Java 11 AND set source and target to 6?

No, it is not a normal Java compile. It is the Gradle Javacard plugin which internally uses the Javacard Ant task which internally uses the Ant compile task and on that also sets the source and target version according to the Javacard SDK used. So no, not really much that can be done there besides rewriting the whole 3rd-party toolchain.

Projects relying on old tech need to stay on old tech 🤷

The Gradle Wrapper should keep it build-able, right?

Of course, that's what I said, I will not be able to easily update that project to Gradle 9 if it requires Java 17

honestly for JavaCard I wonder if you might be better off just using Ant directly instead of a Gradle plugin that tries to wrap it as that seems to be the "supported" toolchain (insofar as the whole ecosystem is supported)

Huh, I thought Java 8 was eol already, my bad. I hope you understand why I thought that given Java 11 is EOL at the same time. Did not Google before opening my mouth

Getting way OT, but I was just wondering is the Gradle Wrapper smart enough to run the selected version of Gradle with a JRE that is known to work with that version? Often Gradle won't run on later Java versions because of incompatibilities with things like

asm

or

groovy

. I didn't see anything in the docs with a quick look. This could be a reasonable enhancement to the wrapper so manual setting of JAVA_HOME isn't needed and the wrapper can launch the daemon with a compatible JVM.

Although oddly enough that image seems to say that it's skeptical whether or not Java 17 is still supported? Yeah I don't think I know how Java determines the length of time it's lts is supported anymore

Once you get past 11 things are less painful.

The post I linked to is more than 3 years old. Things have evolved a bit since then. You have to refer to your vendor's roadmap; e.g. for Eclipse Temurin: https://adoptium.net/support/ (note that 11 is not EOL there; contrary to RedHat: https://access.redhat.com/articles/1299013)

@Scott Palmer "compatible jvm" depends on the build isn't something the wrapper can determine. but you can declare it in https://docs.gradle.org/8.8/release-notes.html#gradle-daemon-jvm-configurable-via-toolchain

Of course, that's what I said, I will not be able to easily update that project to Gradle 9 if it requires Java 17

@Vampire what is preventing you to use a toolchain to keep on building with 11 whilst Gradle itself runs with 17?

If I read him correctly he's talking about a plug-in for Gradle that is the problem

There are so many enhancements. it is often a big job to keep the build scripts updated to the latest best practices. Though improvements in warning messages etc have helped some, I still have tons of builds with explicit

dependsOn

and other ugliness. I would love a consolidated document that takes me through the migration recommendations.

No matter how much they say they aren't there are still cases where explicit depends on is needed

it's legitimate to use on a lifecycle task. which tasks are lifecycle? that's not something encoded in the type system (unless you want to get rid of all ad-hoc tasks?)

If I recall correctly JaCoco also has some valid use cases depending on what you were trying to achieve

Ah, I see now. It is the Gradle Javacard plugin with the issue.

Yes.

> I would love a consolidated document that takes me through the migration recommendations. And what do you know.. It is mostly in one place -https://docs.gradle.org/8.12/userguide/upgrading_version_8.html#upgrading-gradle (I need to read the release notes more carefully. I skipped right over that link.)

@Vampire this one https://github.com/bertrandmartel/javacard-gradle-plugin?

Or if you have a single file source code checker that depends on classes, that would still be wrong (me looking at the built-in check style plug-in)

@ysb33r a fork of it

Another question, would Gradle profit from virtual threads (JVM 21+) if they rewrite all threading/daemon code? 🤔

probably in some areas

it shouldn't require rewriting. but given how heavyweight some other operations are (claasloader switching, launching external processes) I doubt Java thread context switching is noticeable