Hello all, it there a difference in these two pieces of code:

tasks.withType<JavaCompile>().configureEach {
    options.encoding = "UTF-8"
}

and:

tasks.withType<JavaCompile>() {
    options.encoding = "UTF-8"
}

(one has .configureEach and the other one not)

Yes, the first is good, the second is bad.

Thanks!

I feel the need to mention that I'm in favor of them breaking backwards compatibility on this API so that the first and the second do the same thing. It is extremely unintuitive what's lazy and what's eager. The second is a bad API that does the thing you want it to do. The first is a good API that has bad behavior

Maybe I'm misremembering, but isn't the keystone feature of Gradle 9 a bytecode rewriter that makes the second example actually be the first?

There registration API aren't in scope of rewriting for 9.0, only JavaBean-style eager properties are. But it is a nice idea, the infrastructure can handle that. Unfortunately, this is unlikely to happen in 9, but we'll consider expanding the scope of rewrites for 10.

Besides that, Gradle 9 is not yet reality, and even if it is, I guess that would only help consumers using Gradle 9, so it would probably still be preferable to just use the right API 🙂