Kotlin DSL is Now the Default for New Gradle Builds
Table of Contents
Introduction
Kotlin DSL for Gradle was introduced in version 3.0 of the Gradle Build Tool in August 2016 and released as 1.0 in Gradle 5.0. Since then, it’s been growing in popularity and has greatly improved the authoring experience of many Gradle builds.
Kotlin DSL is now the default choice for new Gradle builds. This means that when creating a new project with Gradle, including in IntelliJ IDEA (starting with 2023.1) and Android Studio (starting with Giraffe), Kotlin DSL is the default option. Support for Groovy DSL will continue for existing projects or those who prefer to use it.
In this post, we will explore the benefits of Kotlin DSL and why it is becoming the recommended option for new Gradle builds. We will also discuss some of the improvements that are planned for the future to make Kotlin DSL even better.
About Kotlin DSL #
Kotlin is a powerful language that offers many features that make it an excellent fit for creating a DSL. Its static type system, concise and expressive syntax, and support for functional programming constructs make it easy to create readable and composable DSLs.
Kotlin DSL for Gradle takes advantage of the Kotlin language to enable full IDE assistance for build authoring in IntelliJ IDEA and Android Studio. This includes auto-completion, smart content assist, quick access to documentation, navigation to source, and context-aware refactoring. With Kotlin DSL, you can edit your build logic with the same editing experience you are used to when working with your production and test code.
Gradle combines Kotlin language features with its capabilities to provide an elegant and extensible declarative build language that enables expressing any build clearly and understandably. Dynamically added elements of the build model, like project dependencies (when using version catalog) or subproject names in multi-project builds, benefit from static typing and IDE assistance. Gradle plugins extend Kotlin DSL by contributing extensions and tasks made available statically in build scripts.
Kotlin DSL as default for new builds #
Thanks to the collaborative effort between JetBrains, Google, and Gradle, Kotlin DSL reached the next level of maturity and is now an even more efficient and user-friendly tool for developers.
Many usability improvements, including full support for version catalogs, and faster code analysis and auto-completion in IntelliJ IDEA and Android Studio were delivered. There is also a brand-new DSL reference.
Starting with Gradle 8.2, creating new builds using gradle init defaults to generating Gradle builds using Kotlin DSL.
In IntelliJ IDEA 2023.1, creating a new Java application defaults to using Kotlin DSL.
All wizards and templates default to using Kotlin DSL in Android Studio Giraffe.
Reading the Gradle documentation, you’ll notice that the user manual and samples display Kotlin DSL first. In addition, the documentation for the Kotlin Gradle Plugin and other Kotlin and JetBrains plugins is now 100% Kotlin. The Android documentation, including the Android Gradle Plugin and other Google plugins, recipes, sample applications, and guides, now use Kotlin DSL.
As you can see, this change spans multiple releases of multiple tools. See the related announcements from the JetBrains Blog and Google Blog.
Current limitations and next steps #
This milestone makes Kotlin DSL the default and recommended choice for new projects. We also believe that Kotlin DSL is a better choice for most existing projects. However, very large projects with complex build logic currently using Groovy DSL are advised to wait to migrate. In particular, when changing shared build logic with Kotlin DSL, the script compilation performance is currently slower than with Groovy DSL. Note that Kotlin script compilation outputs can be shared in a remote cache, so this caveat only applies to the person actually changing the shared build logic when using the build cache. While the script compilation performance overhead won’t be noticeable for new projects, it can be problematic for projects with a lot of existing build logic.
There is an ongoing effort to improve Kotlin DSL script compilation performance with continued collaboration between Gradle, JetBrains, and Google. Our next goal is to make Kotlin DSL the recommended choice for large builds too.
You should expect more usability improvements in the upcoming Gradle and IDEs releases. For example, you will soon be able to use the = operator to assign Gradle’s lazy properties and benefit from a streamlined DSL for Gradle’s domain object containers.
Learning more #
If you want to learn more about Gradle’s Kotlin DSL, check out the Gradle Kotlin DSL primer and the updated Kotlin DSL reference. If you are migrating an existing project from Groovy DSL to Kotlin DSL, be sure to read the migration guide.
Join the community chat (#kotlin-dsl channel) and forums to ask questions, share experiences, and contribute to the development of Kotlin DSL.
Your feedback and contributions are highly valued and essential for shaping the future of the Gradle Build Tool.