Kotlin vs Java

JVM.

Overview

Kotlin and Java are the two main JVM languages with very different ergonomics. Kotlin is modern (null safety in the type system, data classes, coroutines, concise syntax); Java is the long-standing incumbent (huge ecosystem, decades of production knowledge, modern features arriving every release). The right answer depends on whether modern ergonomics or ecosystem maturity matters more for the codebase.

• Kotlin: modern JVM language. Null safety, data classes, coroutines, concise syntax. Default for greenfield JVM projects and Android.
• Java: ecosystem maturity. Decades of production knowledge, every JVM library, modern features (records, sealed classes, virtual threads) arriving in recent releases. Default when ecosystem inheritance matters.
• Operational fit per team. Existing Java codebases bias toward Java continuity; greenfield projects with Kotlin-comfortable teams bias toward Kotlin. Both interop on the same JVM.
• Per-codebase choice. Different codebases may pick differently. Document the rationale per codebase rather than enforcing one language org-wide.

The approach

Workload-driven choice, per-team operational fit considered, documented rationale per codebase. The discipline is making the language choice once per codebase with a written reason rather than mixing both languages within the same module.

• Workload-driven. Language per codebase. Reality drives the answer.
• Kotlin for greenfield JVM. Modern ergonomics, null safety, coroutines. Default for new JVM projects and Android.
• Java for legacy or ecosystem-heavy projects. Existing codebase, library inheritance. Default when continuity matters.
• Operational fit plus documented rationale. Team workflow considered; per-codebase rationale captured. Future migrations have a paper trail.

Why this compounds

The right JVM language compounds across years. Code patterns and team expertise align with the language; cross-codebase tooling (build, test, deploy) gets reused. By year two the language choice is automatic per codebase.

• Better operational fit. Language matches team. Velocity stays high.
• Workload-driven decisions. Replaces tribal preference with documented rationale. Quality of choice improves.
• Better engineering velocity. Right language means ergonomics match the work. Iteration speed increases.
• Year-one investment, year-two habit. First language choice is the investment; subsequent codebases inherit the patterns.