Translating 10M lines of Java to Kotlin

Original Article ↗ Hacker News Discussion ↗

Meta’s decision to automate the translation of roughly 10 million lines of Android code from Java to Kotlin is prompting debate over when such large-scale language migrations are worth the cost. Supporters point to Kotlin’s null safety, reduced verbosity, and better fit with modern Android tooling and hiring trends, arguing that even small reliability gains matter at Meta’s scale. Skeptics counter that Java has improved significantly, similar safety can be achieved with existing tools, and a wholesale conversion risks duplicated complexity, unclear ROI, and lost version history—especially when deterministic translators, not AI, are doing the work.

Why Meta Migrated Java → Kotlin

  • Many agree Meta can justify large one‑time investments for modest gains in safety/productivity at their scale.
  • Kotlin is now the de facto Android language; staying on Java is seen as “legacy” and hurts hiring and developer satisfaction.
  • Null‑safety in core frameworks is viewed as critical when 1B+ Android users are affected; even a rare NPE can cost millions.
  • Several argue that partial migration (Java + Kotlin) leaves “nullability chaos”; going all‑in reduces mixed‑language friction.

Perceived Advantages of Kotlin Over Java

  • Less verbosity: data classes, top‑level functions, expression bodies, properties, default immutability.
  • Built‑in null safety without annotations/tooling; nullable vs non‑nullable types enforced by the compiler.
  • Stronger type system: better generics, function types, declaration‑site variance, type aliases, contracts.
  • Language features not easily matched by Java + tools:
    • Extension functions and delegated properties.
    • Sealed classes, exhaustive when, pattern‑matching‑like constructs.
    • Coroutines for async / generators; keyword arguments; interface delegation.
    • Powerful DSL support (scope functions, lambdas with receivers, infix/operators).
  • Multiplatform story (JVM, JS, native, WASM) lets orgs share models/logic across platforms.

Critiques of Kotlin and Counterpoints

  • Some dislike loss of checked exceptions; see unchecked‑only flow as worse, even with Result.
  • Others argue checked exceptions in Java are painful and top‑level handlers + explicit unwraps are enough.
  • Concerns about:
    • Coroutines vs preemptive lightweight threads; function coloring and ecosystem lock‑in.
    • Lambda/DSL style making code hard to read; “every library its own mini‑DSL”.
    • Extension functions scattering behavior across files; harder to see where methods come from.
    • Tooling lock‑in to JetBrains IDE; weaker LSP support than Java.
  • Some see Kotlin as only “marginally better” given modern Java (records, lambdas, Optional, pattern matching, Loom, Valhalla), plus strong Java tooling and static analyzers.
  • Others insist Kotlin is vastly better because Java can’t undo legacy choices (null‑by‑default, mutability, openness).

Android, Ecosystem, and Oracle

  • Android is Kotlin‑first; some newer libraries (e.g., Jetpack Compose) are Kotlin‑only or Kotlin‑centric.
  • Using modern Java on Android can be awkward (desugaring, limited standard library); Kotlin sidesteps this.
  • Several tie Kotlin and Go’s rise partly to unease with Oracle’s stewardship of Java, though others note Kotlin still rides the JVM.

Process, Automation, and AI

  • Meta built an automated pipeline around JetBrains’ Java‑to‑Kotlin (J2K) converter.
  • Deterministic, correctness‑preserving transforms are preferred over LLMs, which can silently produce wrong but compiling code.
  • Some worry about lost git blame granularity; others note careful file moves can preserve history, but per‑line history still gets noisy.