Kotlin.CodeCompared.To/Java

Nothing in Java lives outside a class, so the smallest program needs one — plus the public static void main(String[] args) incantation the JVM looks for by name, plus semicolons, plus System.out.println where Kotlin gives you a top-level println. Every line of this is ceremony that Kotlin either inferred or provided for you, and the ratio does not improve much from here.

Java's var is Kotlin's var exactly — inferred and mutable — but there is no val. Immutability is spelled final, it is opt-in rather than the default, and in practice most Java code omits it, so you lose the at-a-glance guarantee that a local never changes. The inference is also narrower than it looks: var is legal only for local variables. Fields, parameters, and return types always spell out their type.

The JVM has no concept of a top-level function, so kotlinc quietly wraps your file in a synthetic class named after it — Utilities.kt becomes UtilitiesKt, and twice becomes a static method on it. Java simply makes you name that class and write static on every member. The good news: your Kotlin top-level functions were already static methods, so nothing about the calling convention changes. The bad news: MathUtilities.twice(21) is now the shortest form there is, unless you add a import static.

Java generics cannot hold primitives, so a List<int> is impossible and List<Integer> boxes every element — which is why the stream API has separate IntStream, LongStream and DoubleStream types. Autoboxing hides the conversion but not the consequences: == on two Integers compares references, the JVM caches the boxes from −128 to 127, and so the comparison silently reports true for small numbers and false for large ones. Kotlin has this same JVM behavior underneath and simply never exposes it, because Kotlin's == compiles to equals.

The literal pool is what makes this so dangerous: string literals are interned, so == appears to work for as long as your strings come from source code, and starts failing the moment one arrives from a file, a socket, or substring. Use .equals() always, and reach for Objects.equals(a, b) when either side may be null — it is the null-safe version, and the closest thing Java has to Kotlin's ==. Java's identity comparison is ==; Kotlin's is ===. There is no way around learning this one by muscle memory.

Java's inference is strictly local. var works for a local variable, the diamond <> infers type arguments on a constructor call, and lambdas infer their parameter types from the target interface — but a method signature is always fully spelled out, and there is no expression-bodied function whose return type can be inferred. In practice this means every API boundary in Java is explicitly typed, which is more readable to a stranger and more tedious to write.

Nullability is not in Java's type system, so it lives in documentation, in annotations, and in your head. The @Nullable / @NonNull annotations (JSpecify is the emerging standard) are checked by IDEs and static-analysis plugins, never by javac — an annotated violation compiles and ships. The one consolation is helpful NullPointerException messages (Java 14+), which name the exact expression that was null. This is also why Kotlin has "platform types" (String!): when Kotlin calls Java, the compiler has no idea whether null is possible and stops checking, which is the one hole in Kotlin's null safety and the reason a Kotlin/Java mixed codebase still throws NPEs.

Both translations cost something. The explicit guard evaluates getAddress() twice (a real bug if it is not a pure getter) and grows quadratically with the depth of the chain. The Optional version reads closer to the original but allocates a wrapper per hop and only works if you are willing to convert at the boundary. Neither is checked: forget the guard and you get a NullPointerException where Kotlin would have refused to compile.

The pieces are all there, just spelled out: Objects.requireNonNullElse(value, fallback) is ?:, the plain ternary value != null ? value : fallback works too, and Objects.requireNonNull(value, message) is the throwing form — though note it throws NullPointerException, not IllegalArgumentException, which is the JDK convention for a null argument. What you lose is the ?: return form: Elvis works because Kotlin's throw and return are expressions of type Nothing, and Java has neither.

The translation table is short: ?: is orElse, ?.let is ifPresent or map, and !! is orElseThrow. The difference is that String? costs nothing at run time — it is the same reference, and the check is erased — while Optional<String> is a real object wrapped around your value on every call. That cost drives the convention: use Optional for return types only, never for fields or parameters. And note the trap Kotlin does not have — Optional is itself a reference, so a badly written method can return a null Optional.

Every ${…} becomes either a + or a format slot, and the + form has a genuine footgun: once one operand is a String the whole left-to-right chain is concatenation, so "Next year: " + age + 1 produces Next year: 361 rather than 37. Wrap arithmetic in parentheses, or use formatted. The compiler turns a + chain into an efficient StringBuilder-equivalent for you, so the performance folklore about concatenation is out of date — except inside a loop, where you should still build a StringBuilder yourself.

Text blocks (Java 15+) are a straight upgrade on Kotlin's raw strings in one respect: the incidental indentation is stripped by the compiler based on where you put the closing """, so you never forget a trimIndent(). They are worse in the one that matters more — no interpolation — so the values come in through formatted or +. Escapes still work inside them if you need them (\n, and \ at end of line to suppress the newline).

The List interface declares add, and immutable implementations satisfy it by throwing UnsupportedOperationException — so the mistake Kotlin catches at compile time becomes a crash in production. In exchange, Java's immutability is stronger where it exists: List.of and List.copyOf are genuinely immutable, while Kotlin's listOf returns a read-only view that someone holding the underlying MutableList can still change beneath you. Watch also for Arrays.asList and Collections.unmodifiableList, two older half-measures that behave differently again.

Every transformation is bracketed by .stream() and a terminal operation, which is a lot of ceremony for a single map. The upside is that the pipeline is lazy and fused — one pass over the data, no intermediate lists — where Kotlin's eager operators allocate a new list at every step (which is exactly what asSequence() exists to avoid). mapToInt is the boxing tax made visible: generics cannot hold int, so summing needs the primitive-specialized IntStream. And Collectors is a whole vocabulary to learn — groupingBy, partitioningBy, toMap, joining — where Kotlin just has methods.

The to infix and the [] operator are both Kotlin conveniences with no Java equivalent: you write Map.of(key, value, key, value, …) (up to ten pairs, then Map.ofEntries) and call get/put by name. In return, Java's merge and computeIfAbsent are genuinely excellent — counts.merge(word, 1, Integer::sum) is a whole word-count in one line. One trap: Map.of deliberately randomizes its iteration order (to stop you depending on it), so never print or iterate one and expect stability.

Everything you learned about sequences transfers directly — take is limit, onEach is peek, generateSequence is Stream.iterate — and you no longer have to decide, because Java has no eager alternative. The flip side is that there is no cheap path for a one-step transformation: names.map { … } in Kotlin is a single method call, while in Java the same thing pays for a stream, a lambda, and a collector every time.

The arrow form fixed the two historical horrors — implicit fallthrough and the mandatory break — and yield is the block arm's return. Two things do not come across. Java's switch must have a subject, so Kotlin's subject-less when { cond -> … } (a chain of arbitrary boolean tests) has to become an if/else if chain. And case labels must be constants, so a range test like in 500..599 becomes a guard, an if, or a default arm that does the check itself.

case Integer number is is Int plus its smart cast in a single token, and when guards are the &&. Record deconstruction — case Circle(double radius) — actually goes beyond Kotlin, which has no destructuring inside a when. The one thing to burn into memory: a switch on a null subject throws NullPointerException unless you write case null explicitly. It does not fall through to default. Kotlin's when handles null like any other value.

Java's if produces no value, so the assignment moves inside the branches. The final String verdict; declaration-then-assign pattern is worth adopting anyway: definite-assignment analysis will reject the code if any path leaves the variable unset, which recovers a weak version of the guarantee Kotlin gives by making if an expression. The ternary covers the simple cases, and nests legally but illegibly — three levels deep is where reviewers start objecting.

The three-clause for is back, and it is the only way to count down or step by twos. IntStream.range (exclusive) and rangeClosed (inclusive) cover the functional cases, but they are streams, not values — so x in 1..5 becomes a hand-written x >= 1 && x <= 5. That is the real loss: a Kotlin range is an object you can store, pass, and test membership against; Java has no such type outside of a stream you can only consume once.

The one-line function is three lines now, and that is most of Java's reputation for verbosity in one sentence. The subtler difference is Unit versus void: Unit is an ordinary type with exactly one value, so it can be a generic argument — Function<String, Unit> is fine, and that is why Kotlin lambdas returning nothing compose like every other lambda. void is not a type, which is precisely why java.util.function needs a separate Consumer<T> interface instead of reusing Function<T, Void>.

Each default becomes another overload, and because the overloads are positional you can only omit a suffix of the parameter list — that last Kotlin call, which keeps the default salutation but changes the punctuation, has no Java equivalent short of passing "Hello" explicitly. This is also why so much Java uses the builder pattern. (Going the other way, @JvmOverloads on a Kotlin function tells the compiler to generate exactly these overloads for Java callers.)

Forty lines of builder against one data class, and the builder is the recommended Java style. Parameter names are not even in the bytecode unless the class was compiled with -parameters, which is part of why Java never added named arguments: there was nothing reliable to name. Libraries like Lombok generate the builder for you with @Builder, which is what most large codebases do — a code generator standing in for a language feature.

The mechanics are identical — inside the method, numbers is a plain array either way — but the call site differs: Java's varargs parameter simply is an array, so passing one needs no operator, while Kotlin distinguishes the two and requires * to spread. Java has no spread operator at all, which becomes annoying the moment you want to pass an array plus one extra element (you build a new array). Both require the varargs parameter to come last.

You get the generated constructor, accessors, equals, hashCode and toString — the whole point of a data class. Four differences matter. A record is always final and always immutable (there is no var component), where a Kotlin data class can be neither. The accessors are name(), not getName(), which surprises older frameworks. There is no copy(). And destructuring works only inside a pattern switch, not in an assignment — Java has no componentN convention.

copy() is built out of named arguments and defaults, so a language with neither cannot have it. The workaround is one hand-written wither per field, which is code that must be updated every time the record gains a component. Rebuilding the record in full is worse than it looks: add a field, and every call site still compiles while silently dropping the new value — or, if two components share a type, quietly swaps them. A language-level "derived record creation" (ada with { age = 37; }) has been proposed for Java but has not shipped.

Properties are a Kotlin feature, not a JVM one: val width already compiles to a private final field plus a getWidth() method, so this Java class is roughly what kotlinc was emitting all along — you are just writing it out. What is genuinely gone is the syntax: box.area becomes box.getArea(), assignment becomes setHeight(…), and there is no way to add a computed property to look like a field. The getX/setX naming is the JavaBeans convention, and frameworks (Jackson, Hibernate, Spring) find your state by reflecting over exactly those names — so the convention is load-bearing, not cosmetic.

In Java every non-final class is an extension point whether you designed it as one or not, so "design for inheritance or prohibit it" is advice you must follow deliberately rather than a default the compiler enforces. The sharper trap is @Override: it is an annotation, not a keyword, and it is optional. Leave it off and misspell the method name and you have silently added a new method rather than overriding an existing one — a bug Kotlin makes impossible by requiring override. Always write @Override; every linter will insist anyway.

The call sites look nearly the same, but the machinery underneath is not. A companion object is a real object — it can implement an interface, be assigned to a variable, and be passed to a function; static members are not values and cannot do any of that. Kotlin's object declaration gives you a singleton the language guarantees is initialized once and lazily; in Java you pick between the enum trick (the safest), a static holder class, or a hand-written getInstance() with all the double-checked-locking folklore that entails. And static initialization order is back on your list of things to worry about.

Nothing is lost at run time, because nothing was ever there: fun String.shout() already compiles to a static method taking the receiver as its first argument, which is literally StringUtilities.shout(text). What is lost is everything the syntax bought you — the value goes first so calls chain left to right, autocomplete on the value discovers the function, and the whole thing reads as if the type had grown a method. Java's reverse-Polish Utilities.of(Utilities.of(x)) is why Java codebases have so much less of this kind of small, composable helper in the first place.

Scope functions are extension functions that take a lambda with a receiver, and Java has neither extensions nor receivers — so there is no way to write them, not even as a library. Each one decomposes into ordinary statements: apply becomes a local variable plus assignments, let on a nullable becomes Optional.ofNullable(…).map(…) or an if, also becomes a separate line. The code still works; it just stops being a single expression, and the "configure this object right here" idiom that makes Kotlin initialization so compact is gone.

The permits clause is the one piece of extra bookkeeping — Kotlin infers the permitted subtypes from the file, while Java asks you to list them (you may omit permits only if every subtype is in the same file). The exhaustiveness guarantee is the same and just as valuable: add a fourth Payment, and every switch that does not handle it stops compiling. One limit worth knowing: exhaustiveness applies to switch, never to a chain of if (x instanceof …), so the check only protects the code that opted into the construct.

Kotlin's enum class is a Java enum — same bytecode, same valueOf, same ordinal, same ability to hold state and methods — so this is the smoothest translation on the site. The visible differences: the constructor parameters move out of the header and into a hand-written constructor plus fields, and Planet.entries becomes Planet.values(). That last one is not just a rename — values() allocates a fresh array on every call (it has to, since arrays are mutable), which is why Kotlin added entries. If you call it in a hot loop, hoist it into a static final list.

Three habits to unlearn. There is no it, so every lambda names its parameter. There is no trailing-lambda syntax, so the lambda stays inside the parentheses — which is the reason Java has no DSL-style builders (html { body { … } } is simply not expressible). And a lambda is not a value of a function type; it is an instance of an interface, so you invoke it by calling that interface's single method: apply for Function, test for Predicate, accept for Consumer, run for Runnable. Method references (String::toUpperCase) are the one place Java is arguably nicer than Kotlin's ::, since they work on instance methods of the parameter.

The translation table: (T) -> Boolean is Predicate<T>, (T) -> R is Function<T, R>, (T) -> Unit is Consumer<T>, () -> T is Supplier<T>, and two arguments means BiFunction (there is no TriFunction — past two, you declare your own @FunctionalInterface). Because the types are nominal rather than structural, two interfaces with identical shapes are not interchangeable, and generics force boxing unless you reach for the primitive specializations (IntPredicate, IntUnaryOperator, …). Kotlin's inline higher-order functions compile the lambda away entirely; every Java lambda is an object.

Java captures locals by value, so a captured variable must be final or effectively final (never reassigned after initialization) — otherwise the lambda and the enclosing method would disagree about its value. Kotlin captures by reference: it quietly wraps a captured var in a Ref object so the closure really can mutate it. Java makes you do that wrapping yourself, with an AtomicInteger, a one-element array, or a mutable holder object. The rule only applies to the variable, not to what it points at, so mutating a captured List is fine — which is why the names example needs no workaround.

The shape survives: the try-with-resources block is coroutineScope (closing the executor waits for its children), and submit is launch. What does not survive is the type system's knowledge of it. suspend marks a function as one that can pause, and the compiler rewrites it into a state machine; Thread.sleep is an ordinary blocking call that nothing in the signature announces, so you cannot tell a blocking method from a fast one by looking. Cancellation is also different in kind: coroutines have a cancellation tree that propagates automatically, while Java has cooperative interrupts you have to check for and re-assert by hand, as above.

async is supplyAsync, await() is join(), and awaitAll is allOf(…).join(). Three things bite. A CompletableFuture starts running the moment it is created — there is no lazy async, and no scope that owns it, so a forgotten future leaks instead of being canceled with its parent. Its exceptions arrive wrapped in CompletionException. And thenApply/thenCompose chains bring back exactly the callback style that suspend exists to eliminate — compare the last line of each column. In new code, prefer virtual threads to CompletableFuture: blocking is cheap now, so the sequential style is once again the right one.

The exception hierarchy splits in two: anything under RuntimeException or Error is unchecked and behaves exactly like every Kotlin exception, while everything else — IOException, SQLException, InterruptedException — is checked and must be declared or handled. The consequence you will hit fastest is in lambdas: a lambda cannot throw a checked exception unless its functional interface declares one, and none of the java.util.function interfaces do. That is why so much Java code wraps IOException in a RuntimeException inside a Stream.map — the language feature and the library are working against each other.

There is no Result type in the JDK and no runCatching, so "try this, fall back to that" becomes a small helper method or an assign-in-every-branch block. The deeper difference is in the standard library: Kotlin gives you toIntOrNull, firstOrNull, getOrNull — a whole family of functions that return null rather than throwing — while Java's Integer.parseInt throws, and its equivalents mostly do too. Exceptions end up carrying ordinary control flow far more often, and that is a habit of the ecosystem as much as of the language.

One of the few Kotlin idioms that translates without any loss — and arguably improves. use is an inline extension function on Closeable; try-with-resources is syntax, and it handles several resources in one header (closed in reverse declaration order) and attaches any exception thrown by close() to the primary exception as a suppressed exception rather than losing it. Both are built on the same AutoCloseable interface, so a class written for one works with the other.