Calling Kotlin from Java

The reverse direction - calling Kotlin from Java - also works, but it's the direction that needs a little care. Kotlin has features Java doesn't (default arguments, top-level functions, companion objects, properties), and when Java calls Kotlin, those features have to be expressed in terms Java understands. A handful of @Jvm... annotations let you control exactly how your Kotlin appears to Java callers - essential when you're writing Kotlin that a Java codebase must consume.

The mismatch: Kotlin has things Java lacks

Java sees Kotlin as ordinary bytecode (last lesson), but some Kotlin conveniences translate awkwardly by default:

• Default arguments - fun greet(name: String = "world") is one function in Kotlin, but Java has no default parameters, so by default Java can only call it with all arguments supplied.
• Top-level functions - Java can't call a function outside a class, so Kotlin puts it on a FileNameKt class as a static method (which Java must reference by that generated name).
• Companion objects - Kotlin's replacement for static members lives in a nested Companion object, so Java sees MyClass.Companion.create() rather than MyClass.create().
• Properties - a Kotlin val/var is a getter/setter to Java, not a field.

These aren't broken - they just look clunky from Java unless you nudge them. That's what the annotations do.

The @Jvm annotations

Four annotations cover almost every "make this nice for Java" need:

• @JvmStatic - on a companion-object member, generates a real static method so Java calls MyClass.create() instead of MyClass.Companion.create():

class InvoiceFactory {
    companion object {
        @JvmStatic fun create(id: String) = Invoice(id)   // Java: InvoiceFactory.create("A")
    }
}

• @JvmOverloads - on a function with default arguments, generates overloaded methods for each combination, so Java can call it with fewer arguments:

@JvmOverloads
fun greet(name: String = "world", loud: Boolean = false) { ... }
// Java gets: greet(name, loud), greet(name), and greet()

• @JvmName - renames the generated class or method Java sees. Useful to give a top-level-functions file a clean class name (@file:JvmName("Pricing") so Java calls Pricing.applyTax() not PricingKt.applyTax()), or to resolve a signature clash.
• @JvmField - exposes a Kotlin property as a plain public field (no getter) when Java code expects direct field access.

Reach for these when - and only when - your Kotlin is meant to be consumed by Java.

Design for the consumer

The practical rule: if Kotlin code has Java callers, design its public API with them in mind. A pure-Kotlin module with no Java consumers needs none of these annotations - the interop machinery is invisible within Kotlin. But a Kotlin library or shared module used by Java should:

• Add @JvmStatic/@JvmOverloads to factory methods and functions with defaults, so Java calls read naturally.
• Use @JvmName/@file:JvmName to give top-level function files a clean class name.
• Consider whether Java callers need the null-safety guarantees carried across (Kotlin's non-null types emit runtime null checks that protect Java callers too).

This mirrors the API-design principle from the Architecture path: your public surface is a contract, and here the consumer's language shapes what a good contract looks like.