The K2 compiler shipped. Multiplatform went stable. Java landed records, pattern matching, and virtual threads. The gap genuinely narrowed — and that deserves an honest conversation.
1. Setting the scene: why this matters now
For a long time, the Kotlin vs Java debate felt almost settled — at least emotionally. Kotlin won developer hearts with its concise syntax, built-in null safety, and elegant coroutines, while Java was often described as “verbose but reliable.” However, that narrative has slowly but surely started to shift.
Java 21 arrived as a landmark LTS release in September 2023, bringing pattern matching for switch (JEP 441), record patterns (JEP 440), sealed classes, and most importantly, virtual threads via Project Loom (JEP 444). Meanwhile, Kotlin shipped its 2.0 release in May 2024 with the fully stable K2 compiler — a ground-up rewrite that delivers dramatically faster build times and a foundation for years of language innovation ahead.
In other words, both languages had major milestones within twelve months of each other. So instead of relying on arguments that were true in 2021, it’s worth sitting down in 2026 and asking the question fresh: which language should you actually start a new JVM project with?
Quick note on scopeThis article focuses on new, greenfield JVM projects — not migrating existing codebases. If you’re already running Java in production, the calculus is different and migration costs deserve their own piece.
2. The K2 compiler: Kotlin’s biggest internal upgrade
The K2 compiler is arguably the most significant thing that happened to Kotlin in years — not because it changed the language’s surface syntax, but because it fundamentally changed what’s possible going forward.
The old K1 compiler had two separate data structures for type checking, which made it slower and harder to extend. K2 replaced that with a single unified data structure that carries more semantic information. The result? Compilation speeds that are, in some projects, nearly twice as fast as before.
K2 vs K1 compiler: clean build time reduction
Beyond raw speed, K2 brings smarter type inference and more accurate smart casts. For instance, Kotlin 2.0 can now smart-cast variables that were declared outside an if block and used inside one — something K1 couldn’t reliably do. Additionally, the new compiler separates common and platform source sets more strictly in Kotlin Multiplatform, which eliminates a whole class of subtle cross-platform bugs.
There’s also an IDE story here. IntelliJ IDEA 2025.1 ships K2 mode enabled by default, delivering 1.8× faster code highlighting and 1.5× faster code completion on large codebases. For day-to-day developer experience, that’s a meaningful improvement.
Bottom line on K2: K2 isn’t just a performance patch — it’s a platform reset that makes future Kotlin features cheaper to ship. JetBrains can now add language innovations across all targets (JVM, JS, Native, Wasm) from a single compiler architecture.
3. Where Java 21+ genuinely caught up
It’s important to give credit where it’s due: Java has been moving fast. Through Project Amber, the language has absorbed several features that used to be Kotlin’s selling points. Let’s be specific about what arrived and what it means.
Records: finally, data classes
Java 16 made records stable, and by Java 21 they’re idiomatic. A Java record gives you an immutable data carrier with auto-generated constructors, accessors, equals(), hashCode(), and toString() — exactly what Kotlin’s data class has offered since 2016. The syntax is different, but the problem solved is the same. That said, as one detailed language comparison notes, Kotlin’s data class still supports mutable properties, copy-with-modifications via copy(), and component destructuring out of the box — Java records are deliberately immutable and more limited.
Pattern matching and sealed types
Java 21 brings pattern matching for switch with full type patterns and record destructuring. This is genuinely good. You can now write exhaustive switch expressions over sealed type hierarchies with compiler-checked completeness. However, Kotlin’s when expression has been doing this since version 1.0, and arguably with cleaner syntax — particularly when combined with sealed classes and smart casts. As independent benchmarks observe, Java 21 caught up significantly here, but Kotlin’s version is still more ergonomic for domain modeling.
Virtual Threads (Project Loom)
This is Java’s biggest addition in years. Virtual threads, finalized in JEP 444, let you write simple blocking code that the JVM multiplexes onto a small pool of OS threads. You can create millions of them cheaply. Furthermore, the model is backwards-compatible — you don’t need to change your code structure. This is a major narrative shift, and we’ll cover it properly in the concurrency section below.
| Feature | Kotlin 2.x | Java 21+ | Verdict |
|---|---|---|---|
| Data / value types | data class (stable, mutable ok, copy()) | records (immutable only) | Kotlin edge |
| Null safety | Built into type system (String vs String?) | Optional, annotations, no type-level safety | Kotlin wins |
| Pattern matching | when + sealed classes (since 1.0) | switch patterns + record patterns (Java 21) | Near parity |
| Concurrency | Coroutines (library, structured, cancellable) | Virtual threads (JVM-native, blocking style) | Context-dependent |
| Extension functions | First-class language feature | Not available | Kotlin wins |
| Type inference | Full inference everywhere | var only (local variables) | Kotlin edge |
| Compile speed (clean) | Fast with K2 (up to 2× faster than K1) | Generally fast, mature javac | Comparable |
| Ecosystem maturity | Excellent on JVM; growing multiplatform | Unmatched — decades of libraries | Java wins |
| Multiplatform | Android, iOS, Desktop, Server, Wasm (stable) | JVM only | Kotlin wins |
| Learning curve | Moderate (new idioms, coroutines) | Lower for Java teams | Java edge |
4. Where Kotlin still leads
Even with Java’s improvements, there are areas where Kotlin maintains a genuine, practical advantage that’s worth naming clearly.
Null safety in the type system
This is perhaps Kotlin’s most durable advantage. The distinction between String (never null) and String? (nullable) is baked into the compiler. You simply cannot call a method on a nullable reference without explicitly handling the null case. Java’s Optional is a wrapper, and annotations like @NonNull are advisory — they don’t stop compilation. In practice, this means Kotlin teams write dramatically fewer NullPointerExceptions in production, and the protection comes for free, without discipline.
Extension functions and DSLs
Kotlin’s extension functions let you add methods to existing classes without subclassing. This enables fluent APIs and internal DSLs — think Gradle’s Kotlin DSL, Ktor routing, or Jetpack Compose — that simply can’t be built as naturally in Java. Java has no equivalent feature planned.
Coroutines and structured concurrency
Coroutines bring cancellation, error propagation, and lifecycle-aware scopes to async code. They integrate deeply with Android’s lifecycle, Spring WebFlux, Ktor, and more. While virtual threads handle the concurrency volume problem, coroutines offer richer flow control — and on Android specifically, virtual threads aren’t even available yet.
Language evolution pace
As one expert puts it in a recent interview, “Kotlin is just always quicker with adding new features that developers really crave.” Java evolves through the Java Community Process (JCP), which prioritizes caution and backwards compatibility. Kotlin can ship context receivers, value classes, and new multiplatform targets on a faster cadence.
5. Coroutines vs Virtual Threads: an honest comparison
This is the section most engineers actually care about, so let’s be direct about both sides.
Kotlin coroutines are a library-level solution. They’re cooperative: a coroutine suspends when it hits an await or delay, freeing the underlying thread for other work. They support structured concurrency, meaning child coroutines are cancelled when their parent is, and errors bubble up predictably. They’re also deeply integrated into popular frameworks, including Spring, Ktor, and the entire Android ecosystem.
Java virtual threads take a different approach. They’re JVM-native lightweight threads — you write normal, blocking code, and the JVM efficiently parks virtual threads when they’re blocked on I/O, multiplexing many virtual threads onto a small pool of carrier threads. The key advantage is zero migration cost: existing blocking Java code gets concurrency benefits without a rewrite. As one 2025 breakdown summarizes, coroutines rule client-side (Android), while virtual threads rule server-side JVM workloads.
Practically speaking, if you’re building a new backend service that has no Android or multiplatform aspirations, Java 21 with virtual threads is a completely credible modern concurrency story. If you’re building anything mobile-adjacent, or need fine-grained cancellation and structured error propagation, Kotlin coroutines remain the better tool.
6. Kotlin Multiplatform: the real wildcard
Here’s something that often gets buried in feature comparisons: Kotlin Multiplatform (KMP) went stable in November 2023, and in 2025 it more than doubled its adoption — growing from 7% of Kotlin developers to 18% in a single year, according to JetBrains’ own ecosystem survey.
This matters because KMP changes the value proposition of Kotlin beyond being “better Java.” With KMP, you can share business logic — networking, state management, data processing, validation — between Android, iOS, server, and desktop targets from a single Kotlin codebase. Companies like Netflix, McDonald’s, Forbes, and Cash App have adopted it in production. Forbes, for example, shares over 80% of their logic across Android and iOS using KMP.
Kotlin Multiplatform adoption growth
Additionally, Compose Multiplatform for iOS reached stable in early 2025, with 96% of teams reporting no major performance concerns. This means you can now share UI code too — not just business logic — between Android and iOS. Java simply has no answer to this dimension of development.
7. Build time benchmarks: what the data actually shows
One of the most common criticisms of Kotlin historically was slower compilation compared to Java. The K2 compiler addresses this directly. According to JetBrains’ official benchmarks, the improvements are substantial:
Real-world migration reports back this up. One engineering team reported a 34% reduction in their main compilation step and a 63% reduction in test compilation after upgrading to K2. That’s not a synthetic benchmark — that’s production code.
It’s also worth noting that IntelliJ IDEA’s K2 mode, which became the default in version 2025.1, delivers 1.8× faster code highlighting. For a language where tooling matters as much as runtime performance, this is a meaningful quality-of-life improvement.
Running K2 benchmarks on your own project (Gradle)
# Add to gradle.properties to enable K2 compiler kotlin.experimental.tryK2=true # Then run your normal build and check the output ./gradlew clean build # Optionally, use the official k2-performance-metrics tool from JetBrains # https://github.com/Kotlin/k2-performance-metrics
8. Adoption numbers in 2026
Numbers help ground abstract comparisons. Here’s where both ecosystems stand right now:
Kotlin has reached 2.5 million developers worldwide, ranking 15th in the Stack Overflow 2025 survey with 10.8% usage and 51% of users wanting to continue with it. It’s the 6th most-wanted language for adoption. JetBrains and Spring formalized Kotlin as a first-class citizen, with 27% of Spring developers having used Kotlin for their services.
On the enterprise side, the picture is impressive: Google Workspace runs KMP in production for the Google Docs iOS app. Duolingo ships weekly to 40M+ users with KMP features. AWS’s Kotlin SDK spans 300+ services across 8 platforms. Meanwhile, 95% of the top 1,000 Android apps include Kotlin code — a statistic that underlines its dominance in the mobile space.
Java, on the other hand, remains the undisputed language of enterprise — with decades of libraries, frameworks, and expertise accumulated across the industry. It’s not going anywhere. The honest framing is not “Java is dying” but rather “Kotlin is growing into territory where Java used to be the only choice.”
9. So, which one should you pick?
Rather than give a single blanket answer, it’s more useful to be specific about context. Ultimately, the right choice depends on your team, your targets, and your timeline.
Choose Kotlin when…
- You’re building for Android or mobile at all
- You want to share code across Android and iOS via KMP
- Null safety is a priority (it reduces production NPEs)
- You need rich coroutine-based async with cancellation
- Your team is comfortable with modern language features
- You’re starting a new Spring Boot service and want less boilerplate
Choose Java when…
- You have a large existing Java team and codebase
- Your project is purely server-side with no mobile component
- Virtual threads solve your concurrency needs cleanly
- You need maximum ecosystem compatibility (older frameworks)
- Your enterprise requires long-term LTS guarantees (Java 21 → 2031)
- Your team doesn’t have bandwidth to learn Kotlin idioms
There’s also a pragmatic middle path that many teams already take: use Java for existing services and introduce Kotlin for new modules or microservices. Since both compile to JVM bytecode and are fully interoperable, you can call Kotlin from Java and vice versa without friction. This incremental approach lets teams build Kotlin confidence without betting the entire stack on a migration.
The JVM is the real winnerBoth languages run on the same JVM, compile to the same bytecode, and have access to the same libraries. In most production benchmarks, runtime performance is essentially identical. You’re choosing a developer experience, not a runtime performance story.
10. What we have learned
Over the course of this article, we’ve seen that the Kotlin vs Java decision in 2026 is far more nuanced than it was just a few years ago. Kotlin 2.0’s K2 compiler erased the compilation speed gap, turning what was once a practical disadvantage into a near-draw and setting up the language for faster future innovation. At the same time, Java 21 made real progress with records, sealed classes, pattern matching, and virtual threads — features that genuinely narrow the ergonomics gap rather than just talking about it.
Nevertheless, Kotlin still holds meaningful advantages in null safety, extension functions, coroutine-based structured concurrency, and above all, Kotlin Multiplatform — which has grown from an experiment into a production-proven cross-platform story that Java simply can’t match. For greenfield projects in 2026, the default recommendation leans toward Kotlin, especially for anything mobile-adjacent. But Java with virtual threads is a credible modern choice for pure server-side work, particularly where team expertise and ecosystem depth matter more than language expressiveness.
The most important takeaway, however, is this: the JVM has never been healthier. Whichever language you choose, you’re building on a platform that both JetBrains and Oracle are actively investing in — and that’s genuinely good news for everyone.
