We've spent a lot of time talking about Kotlin's null safety as a "feature of the type system." We know that String can't be null and String? can. But here is the thing: the JVM doesn't know any of that. To the JVM, every reference type is nullable. This has always bothered me—how does Kotlin actually enforce these rules once the code is compiled to bytecode?

Building a "Safety" Trap

To figure this out, I'm going to write a very simple function. I want to see exactly where the "NullPointerException" happens when we bypass the compiler. Let's use a function that processes a username.

fun greetUser(name: String) {
    println("Hello, $name!")
}

If I try to call greetUser(null) in Kotlin, the IDE screams at me. The compiler won't even let me build the project. But remember, the bytecode is just Java. If I can get a null into that function from a Java class, what happens? Let's see if the crash happens inside the println or somewhere else.

Peeking Under the Hood

I'll use the "Show Kotlin Bytecode" tool in IntelliJ and then "Decompile" it to Java so we can actually read it. I expected to see something like if (name == null) throw ... written directly into the method. Instead, I see something a bit more abstract.

public final void greetUser(@NotNull String name) {
   Intrinsics.checkNotNullParameter(name, "name");
   String var2 = "Hello, " + name + "!";
   System.out.println(var2);
}

Look at that first line: Intrinsics.checkNotNullParameter(name, "name"). That's the secret sauce. Kotlin isn't just relying on the type system at compile time; it's injecting "guard" calls at the very start of the function. If you pass a null from Java, the program doesn't crash when it tries to use the string—it crashes the microsecond it enters the function.

Where the Magic Actually Lives

I'm curious about what Intrinsics actually is. It's not some complex runtime engine; it's just a utility class in the Kotlin standard library. If we dive into the source of checkNotNullParameter, it's basically this:

public static final void checkNotNullParameter(Object value, String name) {
    if (value == null) {
        throw new IllegalStateException("Parameter " + name + " must not be null");
    }
}

This is an important distinction. The "null safety" we love in Kotlin is a two-part system. The compiler does the heavy lifting to prevent us from making mistakes, but the Intrinsics calls are there to protect the Kotlin code from the "outside world" (like Java or reflection) where those rules don't exist.

The Cost of Certainty

You might be wondering if this adds overhead. Every non-nullable parameter gets one of these checks. In a massive loop with millions of iterations, does this matter? Usually, no—the JIT compiler is incredibly good at inlining these small checks. But it's a good reminder that "zero-cost abstractions" are rarely truly zero-cost.

Wait, let's try one more thing. What if the variable is local? If I declare val x: String = "Hello" inside a function, does Kotlin add a check there? I'll check the bytecode again. Nope. Nothing. Why? Because the compiler can mathematically prove that a local variable assigned a non-null value can never become null. It only adds the Intrinsics checks at "boundaries"—parameters, return values, and certain casts—where it can't possibly guarantee the state of the data.

📋 Practical Task

Breaking the Null Guard via Java Interop

In this exercise, you will demonstrate that Kotlin's null safety is a compile-time shield that can be bypassed at runtime using Java, and identify exactly where the Intrinsics check triggers.

• Create a Kotlin file with a function fun processData(input: String) that simply prints the length of the input.
• Create a Java class in the same project.
• In the Java class, call processData(null). (Java will allow this because it doesn't respect Kotlin's non-nullable types).
• Run the code and observe the stack trace.
• Identify the specific line in the stack trace that mentions kotlin.jvm.internal.Intrinsics.
• Modify the Kotlin function to processData(input: String?) and observe how the decompiled bytecode changes (specifically, the disappearance of the checkNotNullParameter call).