From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

Quite sad about provider delegates <https://docs.gradle.org/current/userguide/upgrading_version_9.html#kotlin_dsl_delegated_properties>
I think they improved significantly the build legibility.

```w: file:///.../buildSrc/build.gradle.kts:110:17: 'fun &lt;T : Any, U : T&gt; NamedDomainObjectContainer&lt;T&gt;.getting(type: KClass&lt;U&gt;, configuration: U.() -&gt; Unit): PolymorphicDomainObjectContainerGettingDelegateProvider&lt;T, U&gt;' is deprecated. Use 'val element = getByName&lt;Type&gt;(name) { }' instead. See the Gradle 9.6 upgrading guide.```

Also, frankly that's one of thing I had the less issue with, _once you know what they are_ (which is not the hardest concept).

FYI, this is not really announced in the release note of the 9.6.0, but you can find it listed here <https://github.com/gradle/gradle/issues/37555>. Otherwise you have  to go to the upgrade guide.

An there are more discussions that were going on here : <https://github.com/gradle/gradle/pull/37556>

It's very disappointing, the blast radius is significant. As if we didn't have enough to do with our builds. I can understand many of the deprecation and bugs, but this one is a hard buy.

I raised objections <https://github.com/gradle/gradle/issues/37604>, but it was dismissed. I don't think my points were understood.

The only real issue with delegate creation of tasks is `by tasks.creating` without a value is a no-op, but this can be fixed in the near future with <https://kotlinlang.org/docs/unused-return-value-checker.html>.

seeing the large list of deprecations made me glad I always removed those constructs whenever I saw them and replaced them with standard APIs

Well I did that too ! As I didn't want the warnings, but clearly it's not a cold shower, but I'm really not happy by this. As <@U02KX5B7EVC> said, the main issue is addressable.

But to be fair, the property delegates felt like *standard* api (for kotlin DSL).

I mean I did it from the beginning. I never liked them :upside_down_face:

I agree they did feel like a standard api, given they were recommended in the docs. But I disagree that they were ever a good idea. The actual-standard APIs (that work in any context, not just Kotlin DSL) have always been sufficient and easier to understand and maintain

For anyone else who's curious, this is the design doc for this change <https://docs.google.com/document/d/140dOuBcCEDCKLGTiY80NNx2bCQ7dUv8EVFsn4ph86fU/edit?usp=sharing>

I distinctly recall being nudged (by IntelliJ?) to use the property delegate syntax wherever possible

Well it's a solid kotlin feature in my opinion.