So there I was last Tuesday, staring at the “Gradle: Syncing…” spinner for the fourth time before 9 AM. My M2 MacBook Pro sounded like it was preparing for a low-orbit launch. If you’ve worked on a complex Multiplatform project recently, you know exactly what I’m talking about. The tooling has been fighting us for months.
The issue wasn’t even my code. It was the compiler choking on overload resolution whenever I touched a shared UI component in Compose. The Gradle daemon would just spin up, eat 12GB of RAM, and die. Error: ENOMEM. Fantastic. I spent half my mornings just invalidating caches and restarting.
But, hey — the recent 2.3.10 compiler update actually did the trick. I bumped our wrapper to Gradle 8.7, updated the Kotlin plugin, and crossed my fingers. I wasn’t expecting much, to be honest. We’ve been promised faster builds for years, after all. But this time, something actually clicked.
The Sync Actually Works
Incremental build times on our staging branch dropped from 4m 12s to roughly 45 seconds. And the IDE sync didn’t freeze when resolving those massive Compose modifier chains. What really caught my attention, though, was how the tooling handles the newer targets.
I finally started migrating some of our web dashboards to Wasm back in January. Before this update, the IDE was a sea of red squiggles — it couldn’t resolve half the standard library for JS/Wasm targets, even though the command line build worked fine. Now? The syntax highlighting actually matches reality.
I also noticed the JVM reflection calls aren’t dragging down our test suite anymore. We rely heavily on reflection for some legacy dependency injection (don’t judge, it’s a five-year-old codebase). That used to add a solid minute to our CI pipeline. Gone.
Anyway, here’s the exact block I dropped into our shared build script to get the compiler daemon behaving properly:
kotlin {
compilerOptions {
// Forces the new resolution engine to be strict early
// Saves the daemon from memory leaks on bad imports
freeCompilerArgs.add("-Xverify-compiler-dependencies")
// If you're using Compose, this stops the endless re-compilation
freeCompilerArgs.add("-P")
freeCompilerArgs.add("plugin:androidx.compose.compiler.plugins.kotlin:metricsDestination=${project.buildDir.absolutePath}/compose_metrics")
}
}The Hidden Catch
But here’s the gotcha, though — if you run this new setup on an older Java version, it fails silently in CI environments. I kept getting ECONNREFUSED on the Gradle daemon port when testing on a t3.medium EC2 instance running Java 17.
You absolutely need to be on JDK 21 for the memory management to handle the updated compiler daemon properly. The garbage collector in older JDKs just can’t keep up with the burst allocation during the new overload resolution phase. The docs bury this requirement somewhere in a migration guide nobody reads.
Look, build tools are never going to be fun. I still think we overcomplicate our build scripts. But at least I’m not force-quitting my IDE twice a day anymore. Update your plugins, switch your environment to JDK 21, and get your mornings back. I’m going to go get more coffee.