Skip to main content

Engineering Notes

Kotlin versus Java for Android: why we switched in 2018

Written in 2018, a year after Google made Kotlin a first-class Android language, this article argued our mobile practice should prefer it over Java. The argument — conciseness, null safety, full interoperability — has since gone from position to industry default, which makes the original reasoning worth revisiting.

By Bibek Sharma Published Substantially revised 5 min read

Historical project. This article records a 2018 technology assessment. Facts about Kotlin’s status reflect that date; the closing section brings the story up to the present.
Kotlin programming language logo
Kotlin — JetBrains’ statically typed language for the JVM (original article image).

What Kotlin is

Kotlin is a statically typed, open-source language (Apache 2, developed by JetBrains, named after Kotlin Island near St Petersburg) that runs on the JVM and can also compile to JavaScript. Unveiled in 2011 and stable from version 1.0 in February 2016, its defining design decision is full interoperability with Java: Kotlin code calls Java libraries natively, which means adoption can be gradual, file by file, inside an existing codebase. Aggressive type inference keeps the syntax lean while the type system stays strict.

The 2018 case against Java-by-default

The original article quotes the language’s own leadership honestly: JetBrains built Kotlin because existing JVM languages lacked what they needed, and positioned it as “an industrial-strength object-oriented language” that is deliberately a better Java rather than a replacement for it — better, but able to live alongside every line of Java a company already owns. Google’s announcement of first-class Android support at I/O 2017 turned that design into a practical question for every mobile team, ours included: if the platform blesses it and the migration is gradual, what exactly is Java-by-default still protecting?

The four virtues

The 2018 assessment organised the case into four properties, and they remain the correct summary:

  • Concise — drastically less boilerplate: data classes, properties and lambdas remove whole categories of ceremony;
  • Safe — nullability lives in the type system, turning the JVM’s most famous runtime crash, the null-pointer exception, into a compile-time conversation;
  • Interoperable — existing Java libraries, frameworks and colleagues all keep working;
  • Tool-friendly — first-class IDE support, unsurprisingly, from the IDE company that built it.

How the bet aged

Present-day editorial perspective.

Few technology assessments in this archive aged this well. Google declared Android development Kotlin-first in 2019; new Android APIs, samples and Jetpack libraries now assume it, and Jetpack Compose — the platform’s current UI toolkit — is Kotlin-only. The language our 2018 article recommended on promise became the ecosystem’s default on merit, and it is the foundation of the native Android work in our mobile practice today, including the platforms documented in our Upkeep.pro case study. The durable meta-lesson: platform-blessed, interop-preserving migrations are the rare technology bets where being early costs little and being late costs compound interest.