Java aus Kotlin aufrufen

Calling Java from Kotlin is the easy direction - it "just works." Every Java library you know - Spring, Jackson, JUnit, Apache Commons, your own code - is usable from Kotlin with no wrappers, and often reads better in Kotlin than in Java. There's exactly one wrinkle worth understanding deeply: platform types, Kotlin's careful handling of the fact that Java doesn't tell it which values can be null. Master that one concept and Java interop holds no surprises.

It just works

Point Kotlin at a Java class and use it directly - construct it, call its methods, read its properties:

import java.util.ArrayList          // a Java class
import java.time.LocalDate          // Java's date API

fun main() {
    val list = ArrayList<String>()  // Java class, Kotlin syntax
    list.add("hello")
    val today = LocalDate.now()     // static Java method
    println(today.plusDays(7))      // fluent Java API, Kotlin call site
}

Better still, Kotlin often makes Java APIs nicer. A Java getter getName() can be read as a Kotlin property obj.name; a Java method taking a Runnable or other single-method interface can be called with a Kotlin lambda (executor.submit { doWork() }); Java arrays, generics, and varargs all map across. Your Java knowledge transfers wholesale - you're just writing the call sites in Kotlin.

The one wrinkle: platform types

Here's the subtlety. Kotlin's headline feature is null safety: a String can never be null, a String? can. But Java has no such distinction - a Java method returning String might return null, and (usually) the bytecode doesn't say. So when Kotlin calls Java, what type is that returned String?

Kotlin's answer is the platform type, written String! (you'll see it in IDE hints, though you don't type the !). A platform type means: "Kotlin doesn't know if this is nullable - it trusts you." Kotlin relaxes its null checks for platform types, letting you treat the value as either nullable or non-null:

val name: String  = javaObject.getName()   // you ASSERT it's non-null (NPE at runtime if wrong)
val name2: String? = javaObject.getName()  // you treat it as nullable (safe)

This is a deliberate pragmatic compromise: if Kotlin forced every Java return to be nullable, calling Java would be a misery of null checks; if it assumed non-null, you'd get no safety. Platform types put the judgment in your hands at the boundary.

Handling the boundary safely

Because a platform type can secretly be null, the boundary between Java and Kotlin is where interop NPEs hide. Good practice:

• Decide nullability explicitly at the boundary. When you take a value from Java, assign it to a String (you assert non-null) or String? (you handle null) - don't leave it implicit and forget.
• Respect Java's nullability annotations. If the Java code is annotated (@Nullable, @NotNull from JetBrains, JSR-305, or JSpecify), Kotlin reads them and treats the value as properly nullable or non-null - no platform type, full safety. This is why well-annotated Java libraries (like modern Spring) interop beautifully.
• Be defensive with unannotated Java returning values you'll dereference - a wrong non-null assertion crashes exactly where Kotlin's null safety was supposed to protect you.