
annotable parameter count: 2 // invisible, parameter // invisible, parameter 1 annotable parameter count: 2 (visible) fun returnNullable(canBeNull: String?, notNull: String): String? = "dummy data" In this next example, we add two parameters to the returnNullable function. val nonNull: String = returnNullable() // type mismatch Thanks to them, the compiler can throw an error when there are violations, like in this snippet. But they can be used to indicate if a return type is nullable or not. The keys here are the two annotations and Although both return types are Ljava/lang/String, the returnNullable function is marked with While returnNonNullable is marked with themselves, those annotations don’t have any effect on how the JVM executes the bytecode. fun returnNullable(): String? = "dummy data"įun returnNonNullable(): String = "dummy data"īelow is their bytecode. The Kotlin compiler, on the other hand, detects when we try to assign a null to nonNull variable and throws an error.īut what happens when we call a predefined function? Does the compiler need to walk up the call chain and check the source code of each and every function? What if we only have the bytecode and don’t have the source code? Check the return type of a function Both are compiled into Ljava/lang/String. LOCALVARIABLE canBeNull Ljava/lang/String L1 元 0Īs we can see, at the bytecode level, there is no difference between a nullable type and a non-nullable type. LOCALVARIABLE nonNull Ljava/lang/String L2 元 1 Val nonNull: String = null // compiler error Below is the code to define a String and a String? val canBeNull: String? = null

We will start with the simplest case, null safety with a local nullable variable.

The same principle can be applied to any other type. But at the end of the day, Kotlin code is still compiled into bytecode and runs on the JVM.Īs an example, today we will find out how Kotlin distinguishes between the String and String? types when the JVM only knows of Ljava/lang/String. Kotlin distinguishes between references that can hold null (nullable types) and references that cannot (non-nullable types). One of Kotlin’s improvements over Java is null safety. Note: phiên bản Tiếng Việt của bài này ở link dưới.
