Java.CodeCompared.To/Kotlin

Kotlin uses val for immutable bindings and var for mutable ones — a direct replacement for Java's final. Idiomatic Kotlin strongly prefers val; reach for var only when mutation is genuinely required. Unlike Java where final feels optional, in Kotlin immutability is the default and mutability is the exception.

Both Java 10+ and Kotlin infer the type of local variables from the right-hand side. Kotlin extends inference further: it works in function return types, lambda parameters, and many other positions where Java still requires explicit types. Both languages fix the inferred type at compile time — it is not dynamic.

Java 16+ introduced pattern variables in instanceof to avoid the explicit cast. Kotlin's smart cast is more pervasive: after any is type check, the compiler automatically narrows the type everywhere that check is guaranteed to hold — in if-branches, when-expressions, and after null checks. No separate binding variable is needed.

Kotlin data classes auto-generate componentN() methods that power destructuring declarations. val (x, y) = point unpacks both components in one line. Java records have no destructuring syntax — components must be accessed individually via accessor methods.

Kotlin encodes nullability directly in the type system. String can never hold null; String? can. The compiler enforces safe handling — calling a method on a nullable without a null guard is a compile error. Java's type system has no such distinction: String can always be null, and NullPointerException is a perennial runtime hazard.

Kotlin's ?. operator evaluates to null immediately when the left side is null, without evaluating the right side. Chaining person.address?.city is safe regardless of whether address is null — no guard clause needed. Java requires an explicit null check at every step of a property chain.

The Elvis operator ?: returns the left operand if it is non-null, otherwise the right operand — a concise null-coalescing expression equivalent to Java's value != null ? value : fallback. It is especially useful chained with safe calls: person.address?.city ?: "Unknown" reads naturally and handles both a missing address and a missing city.

?.let { } combines a null check with a scope function: when the value is non-null, it calls the lambda with the non-null value as the parameter. Inside the lambda, the parameter is a guaranteed String — no null checks needed. This replaces Java's if (value != null) { use(value); } idiom with a more functional style.

Kotlin string templates use $variable for simple variable substitution and ${expression} for arbitrary expressions. Java requires String.format() or String.formatted() with format specifiers — a less readable approach. Java 21+ text blocks support \{} in a limited form, but standard Java strings have no interpolation.

Both languages support multiline raw strings with triple quotes. Java 15+ text blocks re-indent automatically based on the closing """ position. Kotlin raw strings require an explicit .trimIndent() call to strip common leading whitespace. Kotlin raw strings can also contain string templates: """Hello, $name""".

In Kotlin, == calls equals() by default — it compares content structurally. Referential identity uses ===. In Java, == on objects compares references, and forgetting to use .equals() for strings is a classic bug. Kotlin's behavior matches what developers usually want.

Kotlin strings have idiomatic equivalents for all Java string methods, with a few naming differences: lowercase()/uppercase() instead of toLowerCase()/toUpperCase(), and split() returns a Kotlin List<String> (with a .size property) rather than a Java array (with a .length field).

Kotlin's collection API is split at the type level: List<T> is read-only; MutableList<T> adds mutating operations. The functions listOf() and mutableListOf() create each kind. Java's List.of() returns an immutable list, but the type is still java.util.List — the immutability is only a runtime contract, not a compile-time guarantee.

Kotlin's filter, map, reduce, and other collection operations are extension functions directly on List, Set, and Map — no .stream() conversion step is needed. Java Streams are lazy by default; Kotlin's collection operations are eager. For large datasets, Kotlin Sequence provides the same lazy evaluation as Java Streams.

Kotlin maps are created with mapOf() (read-only) or mutableMapOf() (mutable). The to infix function creates key-value pairs: "Alice" to 95. Subscript notation map[key] replaces map.get(key), and map[key] = value replaces map.put(key, value). Map access returns a nullable type: scores["Alice"] is Int?, not Int.

Kotlin collection operations are eager by default — each step processes all elements before the next. .asSequence() switches to lazy evaluation, where elements flow through the entire pipeline one at a time. This mirrors Java's .stream(): use sequences when working with large collections and you only need a subset of the results.

Kotlin's when is an expression that produces a value — like Java 14's switch expression. The key difference is that when is also a statement and does not require exhaustive cases when used that way. When used as an expression (assigned to a variable or returned), Kotlin requires an else branch unless the subject is a sealed class or enum that covers all cases.

Kotlin's when supports range checks (in 80..89), type checks (is String), and arbitrary boolean expressions in the same construct. Java's switch only matches on exact values for primitives, enums, or strings — range checks require a separate if/else chain. The in keyword in when calls contains() on the range.

In Kotlin, if/else is an expression that produces a value, so there is no ternary operator (? :). The if expression is more readable than the ternary for multi-branch conditions. Java added switch expressions in Java 14, but still retains the ternary for simple binary conditionals.

Kotlin ranges (1..5, 1 until 5, 10 downTo 1 step 2) integrate naturally with for. 1..5 is inclusive; 1 until 5 excludes the upper bound (like Java's i < 5). The for (item in collection) syntax works on any Iterable — the same targets as Java's enhanced for loop.

When a function body is a single expression, Kotlin allows the = expression form — omitting the return type (inferred), the return keyword, and the braces. This is not just syntactic sugar: it signals to readers that the function has no side effects and directly computes a result. Java has no equivalent shorthand; even trivial getters require a full method body.

Kotlin default parameter values eliminate Java's overload pyramids. A single function declaration covers all call sites. Named arguments (ssl = true) let callers skip intervening parameters without positional ambiguity, making call sites self-documenting. Java has no equivalent: callers must provide values for all non-overloaded parameters in positional order.

Kotlin uses the vararg keyword rather than Java's ... postfix. The critical difference is when passing an array: Java accepts an array directly, but Kotlin requires the spread operator *array to unpack the array into individual arguments. The spread operator only works with varargs — not with regular function parameters.

Kotlin infix functions are single-parameter extension functions that can be called without a dot or parentheses: a infixFun b instead of a.infixFun(b). The standard library uses infix functions for to (creating Pair), and/or/xor on numeric types, and until/downTo for ranges. Java has no infix call syntax.

Both Java records and Kotlin data classes auto-generate equals, hashCode, and toString. The key syntactic difference: Java record components are accessed as methods (person.name()), while Kotlin data class properties are accessed without parentheses (person.name). Kotlin data classes also auto-generate a copy() method for creating modified copies.

Kotlin data classes auto-generate a copy() method that produces a modified shallow copy, with only the changed fields specified. Java records have no copy() method — you must call the constructor with all fields, spelling out unchanged ones explicitly. Kotlin's copy() avoids that repetition and is especially valuable for classes with many fields.

For Kotlin data classes, == calls the auto-generated equals() method, comparing all constructor properties structurally. This also applies to Java records through Kotlin's general rule: == always calls equals(). In Java, forgetting .equals() and using == for object comparison is a classic bug — Kotlin's design makes this mistake impossible.

Kotlin extension functions add new methods to existing classes without subclassing or modifying the source. The this inside refers to the receiver instance. Extension functions are resolved statically — they are syntactic sugar over static methods, not true virtual dispatch. Java must use static utility classes like StringUtils.isPalindrome(str); Kotlin lets you write str.isPalindrome().

Kotlin's scope functions (let, run, with, apply, also) execute a block in the context of an object. apply — the most common for initialization — sets the receiver as this inside the block and returns the receiver. This replaces Java's verbose repeated object references during setup. The other scope functions differ in how they expose the receiver (this vs it) and what they return.

Extension properties let you add computed properties to existing types. The get() accessor is called when the property is read. Extension properties cannot have backing fields — they must derive their value from the receiver. Java has no property syntax; computed values on existing types are always static methods.

Kotlin's primary constructor is declared directly in the class header. Properties declared with val/var in the constructor are automatically assigned from the constructor arguments — no this.name = name boilerplate. Java requires explicit field declarations, constructor parameters, and assignment statements for each property.

In Kotlin, classes and functions are final by default — subclassing and overriding require explicit open keywords. Java is the opposite: classes are open for extension unless marked final. The Kotlin approach encourages composition over inheritance and prevents accidental subclassing, a common source of fragile base class problems in Java codebases.

Kotlin interfaces support default implementations directly — no default keyword is needed. Implementing an interface uses : (same syntax as inheritance). An important difference: Kotlin interfaces can have properties, but they cannot have backing fields — property implementations in interfaces must use computed getters.

Kotlin has no static keyword. Class-level members live in a companion object — a singleton object scoped to the class. Companion object members are accessed with the class name (Counter.instanceCount), just like Java static members. The companion object can also implement interfaces, something Java static members cannot do.

Kotlin's object declaration creates a singleton directly — no static factory, no private constructor, no INSTANCE field. The object is lazily initialized on first access and is thread-safe. Java requires the entire boilerplate private-constructor + static-field + factory-method pattern to achieve the same. Kotlin objects can extend classes and implement interfaces.

Both Java sealed interfaces and Kotlin sealed classes restrict the subtype hierarchy to a known set. In Kotlin, when on a sealed class is exhaustive — no else branch needed when all subtypes are covered. Java's sealed switch also enforces exhaustiveness. After a successful is Success check, Kotlin smart-casts the receiver to Success automatically.

Kotlin enum classes mirror Java enums in structure and capability — both support properties and methods on each constant. Kotlin enum classes work naturally with when expressions: when (direction) { NORTH -> ... } without the class prefix inside the block. Kotlin enums can also implement interfaces, giving them a capability Java enums share.

Java lambdas use params -> expression; Kotlin lambdas use { params -> expression } in curly braces. Kotlin function types are written as (ParamType) -> ReturnType, replacing Java's functional interfaces (Function<T, R>, Consumer<T>, Supplier<T>, etc.). Kotlin lambdas are invoked with lambda(args) or lambda.invoke(args), not lambda.apply(args).

When a Kotlin lambda has exactly one parameter and you don't give it a name, it is automatically available as it. This makes short transformations like { it * 2 } or { it.length } concise. Java always requires naming the parameter, even for trivial lambdas. Use an explicit name when the lambda body is long enough that it becomes ambiguous.

When the last parameter of a Kotlin function is a function type, the lambda can be placed outside the parentheses — trailing lambda syntax. If the lambda is the only argument, the parentheses can be omitted entirely. This powers Kotlin DSLs: constructs like buildList { add(1) }, transaction { insert(row) }, and Gradle Kotlin scripts all use trailing lambdas to read like language syntax.

Kotlin's function types ((T) -> R) replace Java's functional interfaces. Method references use :: in both languages, but Kotlin method references are more flexible: String::uppercase matches (String) -> String without the String.CASE_INSENSITIVE_ORDER ceremony. Kotlin also inlines higher-order functions at call sites with the inline modifier, eliminating the lambda allocation overhead.

Kotlin coroutines make asynchronous code read like sequential code. A suspend function can be paused and resumed without blocking a thread. Java's CompletableFuture chains are functional but become difficult to read with error handling and multiple await points. Kotlin's async/await pattern is implicit — calling a suspend function automatically awaits its result.

async { } starts a coroutine and returns a Deferred<T> — Kotlin's equivalent of Java's CompletableFuture<T>. Calling .await() on a Deferred suspends the current coroutine until the result is ready, without blocking a thread. coroutineScope ensures all launched coroutines finish before the function returns.

Kotlin has no checked exceptions — no method is required to declare the exceptions it might throw. Callers decide what to handle based on documentation and context. Java's checked exceptions enforce handling at the call site but lead to throws Exception cascade or try/catch boilerplate that swallows errors silently. Kotlin shares this design with C#, Python, and most modern languages.

In Kotlin, try/catch is an expression that produces a value — the last expression in the try block or the catch block. This eliminates the Java pattern of declaring a mutable variable before the try block and assigning it in each branch. The resulting code is more concise and avoids the need for a mutable var.

runCatching { } wraps a block in a Result<T> — either Success(value) or Failure(exception). It is a clean way to convert exception-based APIs into value-based error handling. getOrElse { fallback }, map { }, and fold { } let you transform the result without explicit try/catch. Java has no built-in Result type equivalent.

Custom Kotlin exceptions inherit from Exception (all unchecked). The primary constructor syntax and the val shortfall property declaration combine what Java requires in three separate steps: a field, a constructor parameter, and a getter. The type annotation in catch (error: ExceptionType) is mandatory — Kotlin's catch clause requires an explicit type.