Is there any major advantage of using kotlin gradl...

# android

[M.Onirban]

Is there any major advantage of using kotlin gradle build script over groovy?

[Dean Djermanović]

Using Kotlin allows for conveniences like autocompletion, better refactoring tools and source-code navigation. You can work in script files just like you would with Kotlin classes, with all support of Android Studio you’re used to. Moreover, autocompletion will prevent you from making typos.
Also, it’s practical to work with a single language across your app and your build system.

[trevjones]

can confirm tooling is vastly better with kts vs groovy.

migration can be tough if you are depending on very much of groovy's dynamics, but well worth the effort IMO.

I usually advocate migrating custom build logic from groovy files to buildSrc kotlin first so you can do it in small chunks. but buildSrc has gotcha's so be careful if you go that route.

[CLOVIS]

One thing is that Kotlin build scripts are slightly slower to compile, but the difference is very small now. It used to be painful.

[CLOVIS]

Especially if you drop buildSrc, it becomes quite fast.

[K Merle]

On the other hand, having groovy gradle scripts gives you greater online documentation and you're not complicating the section for other developers who are not familiar with gradle kotlin dsl. Personally, I think it's unnecessary.

[M.Onirban]

Thanks everyone. I was also thinking if its reasonable to adapt it already @K Merle. For me Gradle issues are hard to track down without online resources.

[gildor]

build scripts are slightly slower to compile, but the difference is very small now

I’m a super early adopter of Kotlin DSL and use it for many projects, but I wouldn’t be so definitive

In some cases it’s significantly slower (especially on first usage), and if you have hundreds of modules even “slightly slower” will cause big speed degration

[gildor]

Especially if you drop buildSrc, it becomes quite fast

It’s still slower. Also buildSrc in many cases is the only good way to have shared configuration between modules with Kotlin. So it’s not like “buildSrc” could or should be easily avoided in Kotlin DSl

[Joost Klitsie]

@gildor now you have the version catalog in gradle 7, so for the thing I was using buildSrc mostly for (sharing dependency versions) I can get rid of it and use this catalog feature 🙂

[gildor]

Well, buildSrc was never a good candidate for dependencies. But if you want to share any other logic between modules, buildSrc and precompiled script plugins is essentially the only viable solution with Kotlin DSL

[CLOVIS]

I've been using buildSrc for very long, but a few weeks ago refreshVersions added a command that automatically migrates project. I've migrated everything and it's both much faster and much easier to upgrade

[gildor]

I completely agree with you, buildSrc is slow if you use dependencies, just because you have to recompile everything when change a single version. But it also true for groovy, it’s just an issue of usage buildSrc for dependencies, not an issue of buildSrc itself or Kotlin DSL

[Anshulupadhyay03]

So can we conclude that kotlin is preferable over groovy ?

[CLOVIS]

Personally, I always use Kotlin over groovy.

[trevjones]

there is some stuff you can do to use buildSrc for versions but not have a classpath change on just a version change.
bit weird, but lets me use the version in both buildSrc and build scripts by generating properties for things in the root gradle.props
adding a new one or renaming will obviously change the file and thus classpath, but for version bumps it stays pretty fast.
basically just a bunch of this:

public val Project.agpVersion: String
  get() = checkNotNull(findProperty("agp.version")).toString()