Why does the consistency check job use

actions/setup-java

and with

cache: gradle

? The consistency check job just calls the Kotlin file and calls

git

afterwards. I don't see where it might need Java or Gradle.

Regarding

actions/setup-java

, I want to use newest-ish JRE (LTS, to not make changes in consistency jobs too often), otherwise the default Java 11 is used (related bug and fix after this change). Java itself is still needed as runtime for Kotlin scripts. About Gradle caching, it’s probably a copy-paste error - you’re right it seems not needed. Not sure how much it influences the running time, but I’ll remove it for the sake of simplicity.

Ah, right, oh course. Yeah, I also had to change the toolchain for the

JavaExec

Gradle task to 17 after you requiring it. I don't really understand why you do as long as you don't use some 17+ lib, though. Kotlin is Kotlin is Kotlin. The bytecode version shouldn't matter much for the lib, should it? The probably only effect would be, that you force consumers to use 17+ while there is absolutely no need to, while at the same time making the consistency check a bit slower due to the need for installing Java 17. May I ask what the reason was for that change? Don't get me wrong, I second that move for any end project. I just don't like it for libs without reason and especially for one where the default in its typical usage scenario is 11. :-)

hmm, maybe you’re right - it’s enough to use some new JDK and keep the bytecode version so that JRE 11 can understand it. You convinced me, I’ll revert these changes: 1 and 2 🙂

Even Java 8 should be enough, I think there the indy for lambdas was introduced. But let's not exaggerate 😄

Java setup step was removed from the consistency check job, I think we can assume it’s good enough 🙂

When do you intend to release that change? Just curious.

as it’s not critical, it will go into the nearest scheduled bi-weekly release, that is February 3rd

The

cache: gradle

even complained actually. 🙂