Calling Kotlin from Java - Deep Dive

Overview - Calling Kotlin from Java

What is it?

Calling Kotlin from Java means using Kotlin code inside a Java program. Kotlin is a modern language that runs on the Java Virtual Machine (JVM), so Java and Kotlin can work together smoothly. This allows developers to mix Kotlin's features with existing Java code. It helps teams gradually adopt Kotlin without rewriting everything.

Why it matters

Without the ability to call Kotlin from Java, developers would have to rewrite entire Java projects to use Kotlin, which is costly and risky. This interoperability lets teams improve code quality and use Kotlin's modern features while keeping their existing Java codebase. It makes adopting new technology easier and faster in real projects.

Where it fits

Before learning this, you should know basic Java and Kotlin syntax and how JVM works. After this, you can explore advanced interoperability topics like calling Java from Kotlin, using Kotlin coroutines with Java, and mixed-language project setup.

Mental Model

Core Idea

Kotlin compiles to JVM bytecode that Java can call just like any Java class or method.

Think of it like...

Imagine Kotlin and Java as two different brands of Lego blocks that fit perfectly together because they use the same connector system. You can build a structure mixing blocks from both brands without any gaps.

Java code  ──calls──▶  Kotlin compiled class
   │                         │
   │                         ▼
 JVM bytecode  ◀───────────── Kotlin source
   │
   ▼
 Runs on JVM platform

Build-Up - 7 Steps

1

Foundation

Understanding JVM Compatibility

Concept: Kotlin compiles to JVM bytecode, the same format Java uses.

Kotlin source code is turned into JVM bytecode by the Kotlin compiler. Java programs run on the JVM and understand this bytecode. This means Kotlin classes look like normal Java classes to the JVM.

Result

Java can load and use Kotlin classes as if they were Java classes.

Understanding that Kotlin compiles to JVM bytecode explains why Java can call Kotlin code without special adapters.

2

Foundation

Basic Kotlin Class Usage in Java

Concept: Java can create Kotlin class instances and call their methods directly.

If you have a Kotlin class like: class Greeting { fun sayHello() = "Hello from Kotlin" } In Java, you can write: Greeting greeting = new Greeting(); String message = greeting.sayHello(); System.out.println(message); This works because Kotlin classes compile to Java-compatible classes.

Result

Java prints: Hello from Kotlin

Knowing Kotlin classes appear as Java classes lets you use Kotlin code naturally in Java.

3

Intermediate

Handling Kotlin Properties in Java

🤔Before reading on: do you think Kotlin properties appear as fields or methods in Java? Commit to your answer.

Concept: Kotlin properties become getter and setter methods in Java.

Kotlin properties like: var name: String = "" are compiled to Java methods: String getName(); void setName(String name); So in Java, you use these methods instead of accessing fields directly.

Result

Java code uses getName() and setName() to access Kotlin properties.

Understanding property access as methods prevents confusion when Java code can't see Kotlin fields directly.

4

Intermediate

Calling Kotlin Top-Level Functions from Java

🤔Before reading on: do you think Kotlin top-level functions become static methods or instance methods in Java? Commit to your answer.

Concept: Kotlin top-level functions compile into static methods inside a generated class.

A Kotlin file named Utils.kt with: fun greet() = "Hi from Kotlin" compiles to a Java class UtilsKt with a static method greet(). In Java, call: String msg = UtilsKt.greet(); System.out.println(msg);

Result

Java prints: Hi from Kotlin

Knowing top-level functions become static methods in a generated class helps you find and call them from Java.

5

Intermediate

Using @JvmName and @JvmStatic Annotations

🤔Before reading on: do you think annotations can change how Kotlin code appears to Java? Commit to your answer.

Concept: Annotations like @JvmName and @JvmStatic customize Kotlin code's Java view for better interoperability.

By default, Kotlin generates class and method names that may be verbose or unexpected in Java. - @JvmName changes the generated class or method name. - @JvmStatic makes companion object methods static in Java. Example: object Utils { @JvmStatic fun greet() = "Hello" } Java can call: Utils.greet(); instead of Utils.INSTANCE.greet();

Result

Java calls Kotlin companion object methods as static methods.

Using these annotations improves Java code readability and usability when calling Kotlin.

6

Advanced

Handling Nullability Between Kotlin and Java

🤔Before reading on: do you think Kotlin null safety is enforced when calling Kotlin from Java? Commit to your answer.

Concept: Kotlin's null safety is not enforced at runtime for Java callers; annotations guide Java but don't prevent nulls.

Kotlin marks types as nullable or non-nullable. When Java calls Kotlin, it sees annotations like @Nullable or @NotNull. However, Java can still pass null to Kotlin methods expecting non-null, causing runtime errors. Example: fun greet(name: String) = "Hello, $name" Java can call greet(null), which crashes at runtime.

Result

Java can cause Kotlin null pointer exceptions if null safety is ignored.

Understanding this gap helps prevent bugs by careful null handling when calling Kotlin from Java.

7

Expert

Interoperability Surprises and Edge Cases

🤔Before reading on: do you think Kotlin inline classes or suspend functions are directly callable from Java? Commit to your answer.

Concept: Some Kotlin features like inline classes and suspend functions require special handling or are not directly callable from Java.

Inline classes compile away but may cause confusing signatures in Java. Suspend functions compile to methods with Continuation parameters, which Java cannot call naturally. To use suspend functions from Java, you must handle Continuation manually or wrap them in regular functions. Also, default parameters in Kotlin generate overloads, but Java sees only the full parameter method unless @JvmOverloads is used.

Result

Java calling Kotlin advanced features requires extra care or wrappers.

Knowing these edge cases prevents runtime errors and helps design Kotlin APIs friendly to Java.

Under the Hood

Kotlin compiler translates Kotlin source into JVM bytecode, producing class files compatible with Java. Kotlin classes become Java classes with methods and fields. Kotlin properties become getter/setter methods. Top-level functions become static methods in generated classes. Annotations guide the compiler to generate Java-friendly names and static methods. Nullability is expressed via annotations but not enforced at runtime for Java callers. Advanced Kotlin features like suspend functions compile into JVM methods with extra parameters, requiring manual handling in Java.

Why designed this way?

Kotlin was designed for seamless Java interoperability to allow gradual adoption and reuse of existing Java code. The JVM bytecode target ensures Kotlin can run anywhere Java runs. Annotations like @JvmName and @JvmStatic were added to solve naming and static method issues Java developers faced. Some Kotlin features like coroutines and inline classes are JVM innovations that don't map directly to Java, so special handling is needed. This design balances Kotlin's modern features with Java compatibility.

┌───────────────┐       ┌───────────────┐
│ Kotlin Source │──────▶│ Kotlin Compiler│
└───────────────┘       └───────────────┘
                                │
                                ▼
                      ┌────────────────────┐
                      │ JVM Bytecode (.class)│
                      └────────────────────┘
                                │
                                ▼
┌───────────────┐       ┌───────────────┐
│  Java Source  │──────▶│ Java Compiler │
└───────────────┘       └───────────────┘
                                │
                                ▼
                      ┌────────────────────┐
                      │ JVM Bytecode (.class)│
                      └────────────────────┘
                                │
                                ▼
                      ┌───────────────────┐
                      │      JVM Runtime   │
                      └───────────────────┘
                                ▲
                                │
                      Java calls Kotlin classes/methods

Myth Busters - 4 Common Misconceptions

Quick: Can Java directly access Kotlin properties as fields? Commit to yes or no.

Common Belief: Java can access Kotlin properties just like Java fields.

Reality: Kotlin properties compile to getter and setter methods, so Java must use these methods, not fields.

Why it matters: Trying to access properties as fields in Java causes compilation errors and confusion.

Quick: Does Kotlin null safety prevent Java from passing null to non-null parameters? Commit to yes or no.

Common Belief: Kotlin's null safety fully protects Kotlin code from nulls passed by Java.

Reality: Null safety is not enforced at runtime for Java callers; Java can pass null causing runtime exceptions in Kotlin.

Why it matters: Ignoring this can cause unexpected crashes and bugs in mixed Java-Kotlin projects.

Quick: Are Kotlin suspend functions callable from Java like normal methods? Commit to yes or no.

Common Belief: Suspend functions are normal methods callable from Java without extra work.

Reality: Suspend functions compile to methods with Continuation parameters, which Java cannot call naturally without wrappers.

Why it matters: Misusing suspend functions from Java leads to complex code and runtime errors.

Quick: Do Kotlin top-level functions appear as instance methods in Java? Commit to yes or no.

Common Belief: Kotlin top-level functions become instance methods in Java classes.

Reality: They become static methods inside a generated class named after the Kotlin file.

Why it matters: Calling them incorrectly in Java causes compilation errors and confusion.

Expert Zone

1

Kotlin's @JvmOverloads annotation generates Java overloads for functions with default parameters, improving Java usability.

2

Companion object methods are accessed via INSTANCE in Java unless annotated with @JvmStatic to appear as static methods.

3

Kotlin inline classes can cause confusing signatures in Java, requiring careful API design to avoid interoperability issues.

When NOT to use

Calling Kotlin from Java is not ideal when using advanced Kotlin-only features like coroutines or inline classes without wrappers. In such cases, consider writing Java-friendly wrapper methods or using pure Java APIs. Also, if null safety is critical, avoid exposing Kotlin APIs directly to Java without null checks.

Production Patterns

In real projects, teams use Kotlin for new modules and call them from existing Java code. They apply @JvmStatic and @JvmName annotations to improve Java API clarity. Wrapper classes handle suspend functions and inline classes. Null safety is enforced by adding runtime checks or using annotations to guide Java developers. Gradual migration strategies rely heavily on this interoperability.

Connections

Java Native Interface (JNI)

Both enable calling code written in one language from another, but JNI is for native code, Kotlin-Java is JVM bytecode interoperability.

Understanding Kotlin-Java interoperability clarifies how JVM languages communicate, contrasting with JNI's native bridging.

Type Systems and Null Safety

Kotlin's null safety is a type system feature that affects interoperability with Java's nullable types.

Knowing how type systems differ helps prevent bugs when mixing languages with different null handling.

Modular Software Design

Calling Kotlin from Java supports modular design by allowing gradual migration and mixed-language modules.

This interoperability pattern exemplifies modularity principles in software engineering.

Common Pitfalls

#1 Trying to access Kotlin property as a field in Java.

Wrong approach:

Greeting greeting = new Greeting();
String name = greeting.name; // Error: 'name' not found

Correct approach:

Greeting greeting = new Greeting();
String name = greeting.getName();

Root cause:

Misunderstanding that Kotlin properties compile to getter/setter methods, not public fields.

#2 Passing null from Java to a Kotlin function expecting non-null parameter.

Wrong approach:

greeting.greet(null); // Compiles but crashes at runtime

Correct approach:

if (name != null) {
greeting.greet(name);
} else {
// handle null case
}

Root cause:

Assuming Kotlin null safety applies at runtime for Java callers, which it does not.

#3 Calling Kotlin suspend function directly from Java without handling Continuation.

Wrong approach:

kotlinCoroutine.suspendFunction(); // Java cannot call this directly

Correct approach:

kotlinCoroutine.wrapperFunction(); // Wrapper calls suspend function internally

Root cause:

Not understanding suspend functions compile to methods with Continuation parameters.

Key Takeaways

Kotlin compiles to JVM bytecode, making its classes and functions accessible from Java like normal Java classes.

Kotlin properties appear as getter and setter methods in Java, not as fields, so Java code must use these methods.

Top-level Kotlin functions become static methods in generated classes named after the Kotlin file, callable from Java.

Null safety in Kotlin is not enforced at runtime for Java callers, so Java can pass nulls causing runtime errors in Kotlin.

Advanced Kotlin features like suspend functions require wrappers or special handling to be used safely from Java.