By now, you're probably comfortable writing pure Kotlin. But in the real world, you're rarely starting from a blank slate. You'll spend a lot of your time working in "mixed" projects where Kotlin has to play nice with legacy Java code. Most of the time, it's seamless. But there are a few spots where the two languages disagree on how the world works, and if you aren't careful, you'll run into runtime crashes that the compiler didn't warn you about.

Integrating with a Legacy User Repository

Let's imagine we're working with a legacy Java library that handles user profiles. I can't change the Java code because it's maintained by another team. Here is the Java class we're dealing with:

public class UserProfile {
    private String username;
    private String bio;

    public UserProfile(String username, String bio) {
        this.username = username;
        this.bio = bio;
    }

    public String getUsername() { return username; }
    public String getBio() { return bio; }
}

Now, I want to write a Kotlin service that processes these profiles. At first glance, this looks straightforward. I'll just instantiate the Java class and access the properties.

class ProfileService {
    fun formatBio(profile: UserProfile): String {
        // Java getters are seen as properties in Kotlin
        return "User ${profile.username}: ${profile.bio.toUpperCase()}"
    }
}

The Trap of Platform Types

Here is where I messed up. When I ran this with a profile that had a null bio, the app crashed with a NullPointerException. I was confused because I thought Kotlin's type system would protect me. But notice the type of profile.bio. In the IDE, it doesn't show up as String or String?—it shows up as String!.

That exclamation mark denotes a platform type. Essentially, Kotlin is saying, "I have no idea if this Java method returns null or not, so I'm just going to let you treat it as non-null. If you're wrong, it's your fault." This is the single biggest pitfall in Java-Kotlin interop. I treated bio as a non-nullable String, called toUpperCase() on it, and since the Java code allowed nulls, I hit a wall.

Hardening the Interop Layer

To fix this, I need to be explicit. I can't trust the Java code to tell me the truth about nullability unless that Java code is annotated with @Nullable or @NotNull. Since I can't change the Java source, I have to handle the ambiguity on the Kotlin side.

I'll rewrite the service to explicitly acknowledge that the bio might be missing. I'll use the safe call operator, which forces me to handle the null case:

class ProfileService {
    fun formatBio(profile: UserProfile): String {
        val bio: String? = profile.bio // Explicitly treating it as nullable
        return "User ${profile.username}: ${bio?.toUpperCase() ?: "No bio provided"}"
    }
}

By assigning profile.bio to a variable typed as String?, I've effectively "tamed" the platform type. Now the compiler will stop me from calling methods on it without a null check.

Bridging the Static Gap

Another common headache occurs when you go the other way—calling Kotlin from Java. Let's say I create a utility object in Kotlin to help the Java team:

object UserUtils {
    fun validateUsername(name: String): Boolean {
        return name.isNotBlank() && name.length > 3
    }
}

If the Java team tries to call UserUtils.validateUsername("Alice"), it won't compile. This is because Kotlin objects are singletons, and Java sees them as a static instance called INSTANCE. The Java developer would have to write UserUtils.INSTANCE.validateUsername("Alice"), which feels clunky and "un-Java-like."

To make my Kotlin code feel natural to the Java caller, I'll use the @JvmStatic annotation. This tells the Kotlin compiler to generate a real static method in the underlying bytecode:

object UserUtils {
    @JvmStatic
    fun validateUsername(name: String): Boolean {
        return name.isNotBlank() && name.length > 3
    }
}

Now, the Java side can call it exactly how they expect: UserUtils.validateUsername("Alice"). It's a small touch, but it's the difference between being a helpful teammate and being the person who makes the Java devs complain about "weird Kotlin syntax."

📋 Practical Task

Fixing the Nullable Order Pipeline

You are integrating a Kotlin billing module with a legacy Java OrderStore. The Java class is provided below. Your task is to implement the BillingProcessor class in Kotlin.

// Existing Java Code (Do not change)
public class OrderStore {
    public String getOrderNotes(int orderId) {
        // In reality, this returns null for 50% of orders
        return (Math.random() > 0.5) ? "Fragile shipment" : null;
    }
}

Requirements:

• Create a Kotlin class BillingProcessor that takes an OrderStore in its constructor.
• Implement a function processOrder(orderId: Int): String.
• Inside this function, retrieve the notes from the OrderStore.
• Crucial: You must handle the platform type correctly. If the notes are null, the function should return the string "No notes for order [id]". If notes exist, return "Processing order [id] with notes: [notes]".
• Ensure you do not allow a NullPointerException to occur, even if getOrderNotes returns null.