What does the configurations are initialized lazily of Gradle 8.14 really means for plugin development? I understand that it doesn't really change anything, as things will just continue to work the same; but what if I want to take advantage of that new lazy initialization? Do I understand correctly that it's only a matter of changing:

val myConf = configurations.create("conf")
/* eager configuration */
myConf.… = …
tasks.register<MyTask>("myTask") {
  someProp.from(myConf)
}

to

val myConfProvider = configurations.register("conf") {
  /* lazy configuration */
  … = …
}
tasks.register<MyTask>("myTask") {
  someProp.from(myConfProvider)
}

and

configurations["someConf"].extendsFrom(myConf)

to

configurations.named("someConf") { extendsFrom(myConfProvider.get()) }

?

Well, I'd say there is a bit more to it. Basically yes, from your side that's right. While you should post a request that

extendsFrom

should accept a provider. Other than that it basically is the same as with task-configuration avoidance. Gradle (hopefully everywhere) treats them as lazy as possible now. And as long as your build script and your plugins do not cause eager realization you will benefit from it. That said, there are quite some plugins that do not yet treat configurations lazy properly right now as Gradle used to also not do it. For example https://discuss.gradle.org/t/configuration-phase-ordering-and-laziness-help-with-project-extensions/50762/20 discovers several such cases in KGP and in JVM dependency conflict resolution plugin.

Gradle (hopefully everywhere) treats them as lazy as possible now.

That's far from being the case though. The

java-base

plugin uses `create`/`maybeCreate` and

getByName

everywhere: https://github.com/gradle/gradle/blob/v8.14.0-RC2/platforms/jvm/plugins-java-base/src/main/java/org/gradle/api/plugins/JavaBasePlugin.java

Basic question but what is there to gain with lazy creation? I somewhat get it for tasks because creating them requires reflection and wiring inputs/outputs and that may be expensive but for configurations, how is creation not a malloc() call basically?

I'd guess the pure creation should be the same and irrelevant. The configuration is the expensive part that you can avoid.

That's far from being the case though. The java-base plugin uses create/maybeCreate and getByName everywhere:

Well, maybe this gets improved in the future, or there are good reasons to eagerly realize those configurations. 🤷‍♂️ The 8.14 release notes say

Similar to tasks, configurations are now realized only when necessary.

and

This change can reduce configuration time and memory usage in some builds.

> The configuration is the expensive part that you can avoid. That's the part I'm not getting, what is there to configure really on a Configuration? The

extendsFrom()

calls? Adding dependencies? That should probably execute in nanoseconds on modern hardware...

AFAIK, Android builds can have a lot of configurations (and don't use the

java-base

plugin) so these might be the projects they're talking about here.

There already is an existing issue regarding extendsFrom: https://github.com/gradle/gradle/issues/26732