Kotlin pragmatisch einführen

This module's throughline has been interop; this closing lesson turns it into strategy. Kotlin's superpower isn't any single language feature - it's that its perfect Java interop makes it adoptable one file at a time, so a team can gain its benefits without a rewrite, a rebet, or a risk to what already works. Knowing how real teams introduce Kotlin - and being honest about what it does and doesn't fix - is what turns "Kotlin looks nice" into a defensible engineering decision.

Incremental adoption: the only sane way

Because compiled Kotlin and Java are indistinguishable to the JVM and call each other freely, you never face a big-bang migration. The proven path is gradual:

1. Start with tests. Writing test code in Kotlin is the lowest-risk entry point - tests don't ship to production, Kotlin's conciseness shines in test setup, and the team learns the language on safe ground.
2. Write new code in Kotlin. New classes, new features, new modules go in Kotlin while every existing Java file stays exactly as it is. The two coexist in one build.
3. Convert Java opportunistically - when you're already changing a Java file heavily, converting it to Kotlin (IntelliJ's automated action as a starting point) can be worth it. But never convert working, stable code just to convert it - that's churn and risk for no benefit (the Boy Scout Rule, not a rewrite).
4. Let the codebase become "Java + Kotlin" - and stay that way indefinitely if that's what works. There's no requirement to reach 100% Kotlin; a permanent healthy mix is a completely valid end state.

This is the strangler-fig mindset from the Architecture path applied to a language: migrate at the edges, keep the system running, stop wherever the return no longer justifies the effort.

What Kotlin fixes - and what it doesn't

Be clear-eyed. Kotlin genuinely helps with:

• Null-pointer exceptions - moved from runtime to compile time (within Kotlin).
• Boilerplate - data classes, properties, and concise syntax cut a lot of noise.
• Verbosity and readability - expressions, when, extension functions, scope functions.
• Some classes of bug - immutability by default (val), exhaustive when, no accidental nulls.

Kotlin does not fix:

• Architecture and design problems. A tangled god class is just as tangled in Kotlin - SOLID, DDD, and coupling still decide your fate. A new language doesn't cure a bad design.
• JVM performance characteristics. It's the same bytecode on the same JVM; Kotlin isn't magically faster (and a few features add tiny overhead).
• Team discipline. You can write ugly Kotlin as easily as ugly Java.
• Ecosystem or platform limits. It's still the JVM, still bound by the same runtime realities.

The honest pitch is "a nicer way to write JVM code that eliminates a category of common bugs," not "a fix for your engineering problems."

When "Java + Kotlin" is the right call

Reach for Kotlin when the wins map to your actual pains: a team tired of NPEs and DTO boilerplate, a greenfield service where you can start clean, a codebase where you want incremental improvement without risk. It's an easier sell precisely because it's incremental and reversible - you can try it on one module and back out if the team dislikes it, having risked almost nothing.

Be cautious when: the team has no appetite for a second language (a real maintenance and hiring cost), the codebase is tiny and stable (low upside), or the "problem" Kotlin would solve is really an architecture problem it won't touch. As always, match the tool to the problem - Kotlin is a strong tool with a low adoption cost, not a mandate.