Java Interop

Both Kotlin and Java compile into the same kind of code the JVM runs (bytecode). A Kotlin class becomes a normal JVM class, so Java sees it as just another class, and vice versa. No bridge or wrapper is needed.

When Kotlin calls Java, Java values have no nullability info, so Kotlin can't tell if they can be null. It treats them as 'platform types' and trusts you. If you assume non-null but it's actually null, you get an NPE.

These @Jvm* annotations change the Java-facing shape of compiled Kotlin so Java can call it naturally — making members static, exposing plain fields, renaming, generating overloads for default arguments, or merging top-level functions into one class.

Many Kotlin types are just renamed JVM types (Kotlin String is Java String). Numbers use fast primitives when possible and box only when they must be nullable or generic. Unit becomes void-like; some types like Nothing have no real runtime value.

A Kotlin lambda can stand in for a Java single-method interface (SAM conversion). Kotlin properties show up as getX/setX to Java. And Kotlin's read-only vs mutable list distinction disappears at runtime, so Java can still mutate a 'read-only' list.

Use Kotlin's IntArray for a Java int[]. Array<Int> is an array of boxed Integer objects (Integer[]), which is a different Java type and won't match an int[] parameter.

List has no add or remove methods, MutableList does. But it's only a rule the compiler checks. At runtime both are usually the same Java ArrayList, so the read-only promise can be broken from Java code.

Kotlin lets you write obj.name instead of obj.getName(). It turns Java get/set methods into a property you read and write with a dot. You can still call obj.getName() the old way too.

You call them directly on the class name, just like in Java: Integer.parseInt("42") and Integer.MAX_VALUE. There is no special import or wrapper needed.

A platform type is a value coming from Java whose nullability Kotlin can't know. The compiler relaxes null checks for it. If you treat it as non-null but it's actually null, you get a NullPointerException at runtime.

From Java you call Foo.Companion.create(). Kotlin puts companion members on a nested object named Companion, so Java must go through that object rather than calling the method straight on the class.

Kotlin puts top-level functions into an auto-generated class named after the file plus 'Kt'. So Utils.kt's greet() is called from Java as UtilsKt.greet().

@JvmField turns a Kotlin property into a plain public field. Java code can then read or write it directly as obj.x instead of calling getX() or setX().

@JvmName changes the name that a Kotlin function, getter, or setter shows up as when called from Java. It lets you give Java a nicer name or avoid a name conflict, without changing the Kotlin name.

Java cannot use Kotlin's default argument values. @JvmOverloads tells the compiler to also generate extra Java-visible overloads, one per default-parameter combination, so Java code can call the function while leaving some arguments out.

Kotlin default values live only in Kotlin metadata, not in the compiled method signature Java sees. So Java must pass every argument. Adding @JvmOverloads makes Kotlin also generate the shorter overloads Java can call.

Kotlin lets interface methods have a body. By default the compiler does not put that body on the JVM interface itself; it copies it into a hidden helper class so classes implementing the interface can reuse it.

Java does not see a public field. It sees a private hidden field plus two methods: getCount() to read it and setCount() to change it. Java must call those methods.

Kotlin's Int usually compiles to Java's primitive int, which is fast and uses no extra memory. But when the value can be null or is used as a generic type argument, Kotlin boxes it into Integer instead.

A Kotlin function returning Unit looks like a normal void method in Java. The JVM return type is void, so Java callers just call it and get nothing back.

It is a compile error that happens when two Kotlin functions look different in Kotlin but turn into the exact same method on the JVM, so the JVM cannot tell them apart.

When Java returns a value, Kotlin doesn't know if it can be null, so it trusts you. If you treat it as non-null and it actually is null, you only crash later when you use it.

Kotlin turns a companion object into a static field named Companion plus a nested class. From Java you call MyClass.Companion.method(), unless the member is annotated @JvmStatic, which lets you call MyClass.method() directly.

A single Kotlin property turns into several Java elements (field, getter, setter, constructor parameter). A use-site target like @field: tells the compiler which of those elements the annotation should land on.

Put @JvmName with a different name on at least one of the clashing functions. That gives each a unique method name in the compiled code, so the JVM no longer sees a duplicate.