Kotlin vs Java for Android Development

For a new app, the kotlin vs java for android question has a short answer: write it in Kotlin. Google builds its Android libraries, samples and UI toolkit with Kotlin users in mind, and the recommended UI toolkit cannot be written in Java at all. The harder question is what to do with a Java codebase that already earns money, and that is where most of the budget decisions sit.

This post is for product owners and CTOs who own an Android app and need to plan the next year of work. It covers what differs between the languages in day-to-day code, the interop traps in mixed projects, a migration plan that does not stop releases, and the cases where leaving Java alone is the right call. The language-level case for Kotlin is on our Kotlin app development page, and the Java side is covered under Java app development. Here we go one level more practical.

Google announced in 2019 that Android would become Kotlin-first. Its own page on what Kotlin-first means is specific: new Jetpack libraries, samples, documentation and training are designed with Kotlin users in mind, while Google continues to support calling its APIs from Java. The same page lists Jetpack Compose as “No” for Java and “Yes” for Kotlin, and marks samples and training for Java as best effort.

That is the practical shift. Java still compiles, still runs and still ships on Google Play. But every new screen built in Compose needs Kotlin, and every new sample your developers copy from the documentation assumes it. A Java-only team is now translating the platform’s guidance before using it.

Google also publishes adoption figures. According to Google’s Kotlin page, Kotlin is used by over 60% of professional Android developers and 95% of the top 1,000 Android apps contain Kotlin code. Google also reports that top-1,000 apps using Kotlin have 20% fewer crashes. Treat that last figure as Google’s correlation, not a guarantee for your app: crash rates depend on architecture and testing far more than on syntax.

On tooling, Kotlin 2.0 shipped in May 2024 with the stable K2 compiler, which JetBrains says can potentially double compilation speed, with results varying by project. From Kotlin 2.0 the Compose compiler also lives in the Kotlin repository and releases alongside each Kotlin version, which removed a version-matching headache that used to block upgrades. As of October 2026 the current release is Kotlin 2.4.20.

Syntax comparisons miss the point. These are the differences that change bug counts and review time on an Android team.

Null safety at the boundary, not just inside Kotlin

Inside Kotlin, a String cannot be null and a String? must be checked before use. The compiler enforces it. The catch is Java code: Kotlin sees un-annotated Java values as platform types, and treats them as “could be either”. A Kotlin file that calls a Java helper returning null can still crash with a NullPointerException. In mixed projects, adding @Nullable and @NonNull annotations to the Java classes Kotlin calls most is one of the cheapest stability fixes available.

Coroutines replace hand-managed threads

Older Java Android code moves work off the main thread with executors, callbacks, deprecated AsyncTask or RxJava chains. Each one makes cancellation the developer’s job. Kotlin coroutines tie background work to a scope such as a ViewModel, so leaving a screen cancels the request instead of writing to a view that no longer exists. That one change removes a whole family of “crash after rotation” and “stale result” bugs.

Sealed types make screen state explicit

A screen is usually loading, empty, showing content or showing an error. In Kotlin that becomes a sealed interface, and a when expression fails to compile if a state is not handled. In Java the same idea is a set of booleans or an enum plus nullable fields, and the missing case is found by a user.

Less code per feature

Data classes, default arguments, extension functions and named parameters remove a lot of boilerplate. Fewer lines are not valuable in themselves, but less code means smaller pull requests and faster review, and review time is where Android teams lose days.

Kotlin being the default does not make Java a problem to fix at any cost. Google’s own Kotlin FAQ answers “Kotlin or Java?” with “You don’t have to pick! You can use both.” These are the cases where we leave Java in place.

• Stable modules nobody changes. A payment wrapper or image pipeline that has worked for years and has no roadmap items does not need converting. Spend the budget where change happens.
• An app with a short remaining life. If the product is being replaced within a year, convert nothing. Keep it compliant and stable.
• Shared Java libraries used by a backend team. If a validation library is also used by a Spring Boot service, keeping it in Java can be the simpler contract.
• A Java-only team under a hard deadline. Learning Kotlin mid-release adds risk. Ship, then start the move in the next cycle.

What does not count as a reason: “our Java works”. It does, until the next feature needs Compose, a Kotlin-only library or a developer who would rather not maintain Java. Then the cost lands all at once.

Google describes Kotlin as 100% interoperable with Java, and it is. Interoperable still means someone has to know where the seams are. These are the issues we check for in mixed codebases.

Java calling Kotlin

• Companion objects. Without @JvmStatic, Java callers write Foo.Companion.bar(). Add the annotation on anything Java code still uses.
• Default arguments. Java cannot see Kotlin default parameters unless the function has @JvmOverloads. Otherwise every Java call must pass every argument.
• Checked exceptions. Kotlin has none, so Java callers cannot catch an IOException from a Kotlin function unless it declares @Throws.
• Properties. Kotlin properties appear as getters and setters in Java. Use @JvmField only where a plain field is needed.

Build and tooling

• Annotation processors. Room, Dagger and similar libraries run through kapt in Kotlin modules unless you move to KSP where the library supports it. kapt is slower, so check each processor’s KSP support before a large conversion.
• Lombok. Kotlin code cannot always see Lombok-generated Java members. Convert Lombok-heavy model classes to Kotlin data classes early.
• Module structure. Converting one feature module at a time keeps incremental builds fast and makes the conversion easy to review.

Android developers trained in the last few years learn Kotlin and Compose first. A Java-only Android codebase narrows the pool of people who will want to maintain it, and the same applies when you hand the app to a new vendor. A mixed codebase with clear rules (new code in Kotlin, Java converted on touch) is easy to hand over. A mixed codebase with no rules is not.

When we screen Android engineers, Kotlin is assumed. The useful questions are about seams: how they would call a callback-based Java SDK from a coroutine, what a platform type is and how they handle it, and how they would move a Java module to KSP. If you need people rather than a project team, you can hire Kotlin developers with a two-week trial under the agreement.

Kotlin also opens a route Java does not: Kotlin Multiplatform, which shares business logic such as pricing rules, validation and sync with a Swift iOS app. If that matters to you, read Kotlin Multiplatform vs Flutter before committing to a second codebase.