Kotlin
Completed
-
Section 1: Getting Started
-
Section 2: Core Syntax
-
Section 3: Null Safety
-
Section 4: Object-Oriented Kotlin
-
Section 5: Functional Kotlin
-
Section 6: Coroutines
-
Section 7: Collections Deep Dive
-
Section 8: Type System Deep Dive
-
Section 9: Interop and Tooling
-
Section 10: Kotlin DSLs and Patterns
-
Section 11: Testing and Quality
-
Section 12: Server-Side Kotlin
-
Section 13: Practical Projects
-
Section 14: Interview Practice
-
Section 15: More Practice Exercises
-
Section 16: More Standard Library
-
Section 17: Multiplatform Kotlin
-
Section 18: kotlin.collections In Depth
-
Section 19: kotlin.text In Depth
-
Section 20: kotlin.ranges and kotlin.sequences
-
Section 21: kotlin.io and File Handling
-
Section 22: kotlinx.coroutines Deep Dive
-
Section 23: kotlin.reflect
-
Section 24: Android Development with Kotlin Overview
-
Section 25: Kotlin Multiplatform Deep Dive
-
Section 26: Kotlin for Backend Deep Dive
-
Section 27: Kotlin Design Patterns
-
Section 28: Advanced Language Features
-
Section 29: More Practice Exercises
-
Section 30: More Interview Practice
-
Section 31: Kotlin Type System Deep Dive
-
Section 32: Kotlin Null Safety Advanced
-
Section 33: Kotlin Testing Deep Dive
-
Section 34: Kotlin Build Tooling Deep Dive
-
Section 35: Kotlin Serialization
-
Section 36: Kotlin Performance Considerations
-
Section 37: Kotlin Native Overview
-
Section 38: Kotlin for Data and Scripting
-
Section 39: More Coroutines Practice
-
Section 40: More Android-Adjacent Patterns
-
Section 41: More Practical Projects
-
Section 42: More Design and Architecture Practice
-
Section 43: Kotlin Language Evolution
-
Section 44: More Interview and Review
-
Section 45: Kotlin Delegation Patterns Deep Dive
-
Section 46: Kotlin Annotations Deep Dive
-
Section 47: Kotlin for Gradle Plugin Development
-
Section 48: Kotlin Concurrency Beyond Coroutines
-
Section 49: Kotlin Compiler Internals
-
Section 50: Real-World Kotlin Case Studies
-
Section 51: Final Practice Projects
-
Section 52: Kotlin for Server-Side Reactive Programming
-
Section 53: More Practice and Drills
-
Section 54: Kotlin Security Practices
49: Building with Gradle Kotlin DSL
You've probably seen a million tutorials using build.gradle. But as you move into professional Kotlin development, you'll notice the file extension has changed to build.gradle.kts. That little .kts stands for Kotlin Script, and while it seems like a minor change, it completely changes how the build tool behaves. If you try to copy-paste Groovy code into a Kotlin DSL file, things break immediately.
// build.gradle.kts
dependencies {
implementation 'com.squareup.moshi:moshi-kotlin:1.15.0'
testImplementation 'org.jetbrains.kotlin:kotlin-test'
}
If you try to sync this, Gradle will throw a fit. You'll see an error like Expression expected or Unexpected token. It's frustrating because the code looks correct—you've seen it in a hundred StackOverflow answers. The problem is that you're writing Groovy in a Kotlin file.
Parentheses Are Not Optional
In Groovy, you can often omit parentheses when calling a function. implementation '...' works because Groovy is flexible (or lazy, depending on who you ask). Kotlin is not. In the Kotlin DSL, implementation is a function call. You cannot just place a string next to it and hope for the best.
Here is the fix. You have to wrap your dependency strings in parentheses:
// build.gradle.kts
dependencies {
implementation("com.squareup.moshi:moshi-kotlin:1.15.0")
testImplementation("org.jetbrains.kotlin:kotlin-test")
}
It feels like extra typing, but the payoff is huge. Because this is actual Kotlin code, you now get full IDE auto-completion. You don't have to guess if a property is named group or groupId; you can just hit Ctrl+Space and let the IDE tell you.
Handling Plugins the Modern Way
Another spot where learners usually trip up is the plugins block. In the old Groovy days, you'd see apply plugin: 'kotlin-android' scattered throughout the file. In the Kotlin DSL, we use the plugins { ... } block with a specific id syntax.
If you're trying to add a plugin and it's not resolving, make sure you're using the id()` function. I've seen people try to use the apply keyword inside the plugins block, which just won't work.
plugins {
kotlin("jvm") version "1.9.20"
id("org.jetbrains.kotlin.plugin.serialization") version "1.9.20"
}
Notice the kotlin("jvm") shorthand? That's a helper function provided by Gradle for the most common Kotlin plugins. For anything else, use id("...").
Registering Custom Tasks Without the Magic
One of the most powerful parts of Gradle is creating your own tasks. In Groovy, tasks were often declared "magically" with a simple block. In Kotlin, we use tasks.register. This is "lazy" configuration, meaning Gradle won't actually create the task object unless it's actually needed for the build, which keeps your build times fast.
Let's say you want a task that prints a custom message before your tests run. You'd do it like this:
tasks.register("prepareTestEnvironment") {
group = "verification"
description = "Cleans up temporary test directories."
doLast {
println("Cleaning up /tmp/test-data... Done!")
}
}
The doLast block is critical. If you put the println directly in the register block, it will execute every single time you run any Gradle command (including gradle help), because that block is for configuring the task, not executing it.
📋 Practical Task
Exercise: Implementing a Version-Logging Task and Dependency Sync
You are tasked with updating a build.gradle.kts file for a project that is migrating from Groovy to Kotlin DSL. Perform the following steps:
- Fix the Dependencies: The following block is currently broken. Rewrite it using the correct Kotlin DSL syntax:
dependencies { implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-core:1.7.3' testImplementation 'org.junit.jupiter:junit-jupiter:5.10.0' } - Add a Plugin: Add the
kotlin("plugin.serialization")plugin with version"1.9.20"to thepluginsblock. - Create a Custom Task: Register a new task named
"printProjectDetails".- Assign it to the
"help"group. - Inside a
doLastblock, print a message that says:"Building Project: [Project Name] Version: [Project Version]". (You can use theproject.nameandproject.versionproperties).
- Assign it to the
There are no comments for now.