Why I went back to the Gradle Groovy DSL

About an year ago when I first discovered the Gradle Kotlin DSL, I was very quick to jump on that train. Now it feels like a mistake.

The initial premise of the Gradle Kotlin DSL was very cool. You get first class code completion in the IDE, and you get to write Kotlin rather than the arguably weird Groovy. People were excited to finally be able to write complex build logic using the buildSrc functionality that this change introduced.

However the dream slowly started fading as more and more people started using the Kotlin DSL and the shortcomings became more apparent. My grievances with the Kotlin DSL are multifold as I’ll detail below.

Just a disclaimer, This post is not meant to completely trash the Kotlin DSL’s usability. It has it’s own very great benefits and people who leverage those should continue using it and disregard this post :-)

Build times

The Gradle Kotlin DSL inflates build times significantly. Compiling buildSrc and all the *.gradle.kts files for my app takes upto 10 seconds longer than the Groovy DSL. Couple that with the fact that changing any file from buildSrc invalidated the entire compiler cache for me made iterative development extremely painful.

Half-baked API surface

Gradle doesn’t seem to have invested any actual time in converting the original Groovy APIs into Kotlin-friendly versions before they peddled the Kotlin DSL to us. Check the samples below and decide for yourself.

Groovy

android {
  compileSdkVersion 29
  buildToolsVersion = '29.0.2'
  defaultConfig {
    minSdkVersion 21
    targetSdkVersion 29
  }
  buildTypes {
    minifyEnabled = true
  }
}

dependencies {
  implementation('my.company:fancy.library:1.1.1') {
    force = true
  }
}

Kotlin

android {
  compileSdkVersion(29)
  buildToolsVersion = "29.0.2"
  defaultConfig {
    minSdkVersion(21)
    targetSdkVersion(29)
  }
  buildTypes {
    isMinifyEnabled = true
  }
}

dependencies {
  implementation('my.company:fancy.library:1.1.1') {
    isForce = true
  }
}

I am definitely biased here, but this is not how an idiomatic Kotlin API looks like.

What we should have gotten

android {
  compileSdkVersion = 29
  buildToolsVersion = "29.0.2"
  defaultConfig {
    minSdkVersion = 21
    targetSdkVersion = 29
  }

  buildTypes {
    minifyEnabled = true
   }
}

dependencies {
  implementation('my.company:fancy.library:1.1.1') {
    force = true
  }
}

Property access syntax and discoverable variable names should have been the norm since day one for it to actually be a good Kotlin DSL.

Complexity

The Kotlin DSL is not very well documented outside Gradle’s bits and pieces in documentation. Things like this were incredibly problematic to implement in the Kotlin DSL, at least for me and I found it to be incredibly frustrating.

Conclusion

Again, these are my pain points with the Kotlin DSL. I still use it for some of my projects but I am not going to use it in new projects until Gradle addresses these pains.