Kotlin vs Java

Kotlin and Java are the two primary languages of the modern JVM ecosystem. While Kotlin originally emerged to address Java 6/7/8 boilerplate and Android ergonomics, the modern landscape has shifted: modern Java (Java 17 & Java 21 LTS) has aggressively closed the language feature gap, adopting pattern matching, records, sealed types, and virtual threads.

This comparison analyzes how both languages solve key engineering challenges under the hood on the JVM.

Concurrency: Coroutines (CPS) vs Virtual Threads (Project Loom)

The most fundamental architectural divergence between modern Kotlin and Java 21+ is how they achieve high-throughput, lightweight asynchronous concurrency:

• Kotlin's Model: Explicit, cooperative, compiler-driven. You declare suspension boundaries explicitly with suspend.
• Java's Model: Transparent, runtime-driven. HotSpot automatically parks and unmounts the virtual thread whenever a blocking system call or socket operation occurs.

Null Safety: Static Type Hierarchy vs Optional / Annotations

• Kotlin: Nullability is embedded directly in the static type system:
  • String cannot hold null (enforced at compile time).
  • String? can hold null.
  • Operations like ?. (safe call) and ?: (Elvis operator) compile to branch instructions with zero heap object allocation.
  • Calling Java code creates Platform Types (String!), where Kotlin automatically generates runtime boundary checks (Intrinsics.checkNotNullParameter).
• Java: References are nullable by default:
  • Mitigated via java.util.Optional<T> (which introduces heap wrapper overhead and is not recommended for fields or method arguments).
  • Relies on IDE/compiler static analysis annotations (@NonNull, @Nullable, JSpecify), but these are not enforced by the Java language specification.

Data Carriers: Kotlin data class vs Java record

Both languages provide concise constructs for immutable data carriers, but with different design goals:

Pattern Matching & Control Flow: when vs Modern switch

Modern Java (Java 21+) features sophisticated pattern matching that rivals and in some areas surpasses Kotlin:

Java 21 Record Pattern Matching & Switch

// Java 21+: Pattern matching with record deconstruction and guards
return switch (obj) {
    case Point(int x, int y) when x == y -> "Diagonal point: " + x;
    case Point(int x, int y)             -> "Point: " + x + ", " + y;
    case String s                        -> "String of length " + s.length();
    case null                            -> "Null value";
    default                              -> "Unknown";
};

Kotlin when Expression

// Kotlin: Versatile condition matching
return when (obj) {
    is Point -> if (obj.x == obj.y) "Diagonal point: ${obj.x}" else "Point: ${obj.x}, ${obj.y}"
    is String -> "String of length ${obj.length}"
    null -> "Null value"
    else -> "Unknown"
}

Kotlin's when is more flexible as a general replacement for if/else ladders, while Java's pattern matching switch has deeper integration with record component deconstruction in the compiler grammar.

Method Extensions: Extension Functions vs Static Utilities

• Kotlin Extension Functions:
  • Allows extending existing classes (including third-party libraries and JDK classes) with new methods:

    fun String.toSlug(): String = this.lowercase().replace(" ", "-")
    

  • Compiles to a plain static method in bytecode (public static String toSlug(String $this)).
  • Zero runtime allocation overhead; dispatched statically at compile time.
• Java:
  • Requires explicit static utility classes (StringUtils.toSlug(str)).
  • Java does not support extension methods, preferring default methods on interfaces for library evolution.

Inheritance Defaults & Closed Hierarchies

• Inheritance Defaults:
  • Java: Classes and methods are open for extension by default; must explicitly add final to prohibit subclassing.
  • Kotlin: Classes and methods are final by default; must explicitly add the open keyword to allow subclassing. (Aligns with Effective Java Item 19: "Design and document for inheritance or else prohibit it").
• Sealed Types:
  • Kotlin (sealed class / sealed interface): Restricts subclasses to the same package and compilation module.
  • Java 17+ (sealed class ... permits ...): Restricts subclasses using an explicit permits clause. Both compilers leverage sealed hierarchies to guarantee exhaustiveness in when and switch statements without requiring a default / else branch.

Exception Handling: Checked vs Unchecked

• Java: Enforces Checked Exceptions (IOException, SQLException). Methods must declare them via throws or handle them in try/catch blocks.
• Kotlin: Does not have checked exceptions. All exceptions are unchecked at compile time. Kotlin omits throws clauses, arguing that checked exceptions often lead to empty catch blocks or catch-and-wrap anti-patterns in enterprise codebases.

Architectural Tradeoffs Summary