Let’s look at an example where we don’t know if maybeString is null. This is where I remembered of all the work the compiler does for us. When I decompiled this into Java, it confused me at first. What this does is call length if maybeString is not null and return null otherwise. That’s the question mark after maybeString, and before. Won't compile!!īecause that one won’t compile, we’ll use a different example to decompile. Since maybeString is nullable and we don’t check for null before we call length on it, it won’t compile. If a variable is nullable, and we don’t check for null before we call something on it, it won’t compile. If there is a question mark, it’s nullable.

We notate that a variable could be null by putting a question mark after the type, e.g. By doing this, we run a much lower risk of encountering a NullPointerException. This means that we always know when something could be null, and the compiler forces us to check for it.

One of the things we hear about a bunch when it comes to Kotlin is that nullability is built right into the type system. I’ve found decompiling Kotlin bytecode into Java to be a great tool to help understand what’s going on.

Kotlin null check