Over the past three years 70% of our new Java projects start in Kotlin. No hype, no religion in this post — just the engineering arguments for where Kotlin beats Java on Spring Boot 3 and where we still write plain Java.
Why we pick Kotlin by default
- Null safety at the language level — an entire class of runtime errors gone
- Data classes — DTO code shrinks by ~30% compared to Java records
- Coroutines in Spring 6 — a more ergonomic alternative to WebFlux/Project Reactor
- Extension functions — cleaner domain code without static helpers
- 100% compatibility with the Java ecosystem — no library loss
Where Java is still stronger
- 01High-load low-latency services — Java GC tuning is documented more broadly
- 02Teams where every senior has written Java for 5+ years — retraining costs more than the gain
- 03Static-analysis tooling — Error Prone, SonarJava — still works better with Java
- 04AOP frameworks — some are sensitive to bytecode shape
Our typical stack in 2026
- Spring Boot 3.4 + Kotlin 2.1
- Spring Cloud Gateway + Eureka or Consul
- PostgreSQL 16 + Hibernate 6 with the Kotlin JPA plugin
- Kafka 3.7 with Spring Cloud Stream
- Resilience4j instead of Hystrix
- OpenTelemetry for tracing
- Testcontainers for integration tests
Kotlin doesn't make you an architect. Bad code stays bad — just syntactically prettier. Don't confuse the tool with discipline.
Performance
In real benchmarks Spring Boot 3 on Kotlin barely differs from Java: the gap stays within 1–3% throughput and 2–5 MB of memory. If your performance requirements demand tight control, use GraalVM Native Image (both languages are supported).
Facing a similar challenge in your company?
Tell us about the task — we'll get back within one business day with a call agenda.
Start a project →