Why you should use Gradle w/ the Kotlin DSL to build Kotlin projects
A brief overview of Gradle, Maven & Ant and the pros and cons of using the Kotlin DSL
Have you heard about the Kotlin Primer? It’s an extensive, hands-on and detailed guide to the Kotlin language full of unique and original explanations, interactive exercises, and concrete recommendations based on experience. It will transform anyone who knows Java into a Kotlin expert within a matter of days. Check it out!
This article is the first in a series about creating a Kotlin project with Gradle configured using the Kotlin DSL. The series is written with complete beginners in mind and assumes no previous experience with Gradle, but also strives to provide references to all presented material and to leave no questions unanswered. At times, getting satisfactory answers required digging into the actual source code and, to my knowledge, this information is not available elsewhere at the time of writing. This makes it interesting to more advanced users as well.
In this article, I want to talk about why I chose to build my Kotlin projects using Gradle w/ the Kotlin DSL in the first place.
When setting up a Kotlin project, the first thing you need to look at are build/project management tools. There are three major players that are worth mentioning: Gradle, Maven and Ant. All three support building Kotlin projects, but only Gradle and Maven can also take care of dependencies, which I consider a must. I chose Gradle for a couple of reasons.
Right off the bat, I was discouraged from using Maven because it’s configured using XML, which I dislike for its verbosity and generally find it visually frustrating. But more importantly, Gradle and Kotlin are officially partnered up, which is reflected (among other things) in the Kotlin DSL that Gradle offers to configure the builds. Kotlin itself is built with Gradle, and Gradle is the official build tool for Android, which in turn is one of the main reasons people learn Kotlin in the first place. Therefore, it seems like a sensible choice.
Paradoxically, the Kotlin DSL can actually be the trickiest part of using Gradle. Since Gradle was created in 2007, the language it used for declaring project configurations was a Groovy-based DSL, while the first alpha release of the Kotlin DSL happened mid 2016 and the first major version wasn’t released until mid 2018. This has a couple of consequences, the most painful one being that a large portion of Gradle resources and tutorials you’ll find target Groovy, and translating between the two isn’t always straightforward. It also means that the Kotlin DSL has only been in development for 2–3 years, so there are still some things lacking — for example, there are complaints about a big speed gap between the two DSLs, among other things.
However, it’s not like there aren’t any options. There are steps you can take to make your Gradle builds faster (some of which we’ll discuss in future articles). Gradle imports are already 2.5x faster and use 75% less memory in Kotlin 1.3.60 than they did in Kotlin 1.3.10 — this improvement corresponds to a year of development. Gradle is also investing in creating resources to simplify migration from Groovy to Kotlin. It is reasonable to expect that these trends will continue.
In total, considering that Gradle has clearly committed to turning Kotlin into a first class citizen, I think using the Kotlin DSL is the smart thing to do. They aren’t going to invest this much effort in an initiative only to abandon it in the future, which means they’re going to keep working at it until it’s on par with what one can do with Groovy. And by that time, if for no other reason than marketing and hype, they might very well do the same thing Android did and turn Gradle into a Kotlin-first tool.
In the next article, we’ll take a look at setting up Gradle and creating our first Kotlin project.
