- This is the 30th post in a multipart series.
If you want to read more, see our series index - This follows the introduction to the
byoperator and delegates
A lot of introductions to Kotlin start with how null is opt-in because that makes it safer, we even looked at this way back in post 8. The problem though is that sometimes we do not know what we want the value to be when we initialise the value and we know that when we use it we don’t want to worry about nulls. The ability to change from null to never null might seem to be impossible but Kotlin has two ways to do the impossible.
Before we look at the two solutions, let us look at a non-working example. Here we have a class to represent a physical building and we want to store the number of floors which we get from calling an API (not shown). The problem here is there is no good default value. A house with just a ground floor is 0, a multistory office building could have 10 floors, and an underground bunker could have -30 floors.
class Building() {
var numberOfFloors : Int
fun getBuildingInfo(erfNumber : String){
// call municpality web service to get details
numberOfFloors = 0; // 0 cause 0 = G like in elevators
}
}
fun main(args:Array) {
val house = Building()
house.getBuildingInfo(“123”)
println(“My house, up the road, has ${house.numberOfFloors}”)
}
This will not compile as it states Property must be initialized or be abstract for the number of floors.
notnull
Following on from our previous delegates we have the notnull delegate we can use to allow the property to not be set initially and then
import kotlin.properties.Delegates
class Building() {
var numberOfFloors : Int by Delegates.notNull()
fun getBuildingInfo(erfNumber : String){
// call municpality web service to get details
this.numberOfFloors = 10;
}
}
fun main(args:Array) {
val house = Building()
house.getBuildingInfo(“123”)
println(“My house, down the street, has ${house.numberOfFloors}”)
}
This example will print out that we have 10 floors. If we were to comment out line 14, we would get the following exception: Exception in thread "main" java.lang.IllegalStateException: Property numberOfFloors should be initialized before get. - so not exactly a null exception but close enough it makes no difference.
lateinit
Another option is lateinit which we can add before the var keyword, but we cannot use it with Int, or other primative types so we need to change that as well to a class. This is a really nice and simple solution.
data class Floors(val aboveGround: Int, val belowGround: Int)
class Building() {
lateinit var numberOfFloors : Floors
fun getBuildingInfo(erfNumber : String){
// call municpality web service to get details
this.numberOfFloors = Floors(2, 40);
}
}
fun main(args:Array) {
val house = Building()
house.getBuildingInfo(“123”)
println(“My house, in the middle of the avenue, has ${house.numberOfFloors}”)
}
Once again, if we comment out line 14 we get an exception as expected ‘Exception in thread “main” kotlin.UninitializedPropertyAccessException: lateinit property numberOfFloors has not been initialized’.
lateinit vs. notnull
As we can see in our simple examples both achieve the goal but they both have their own limitations and advantages too:
-
notnullbeing a delegate needs an extra object instance for each property, so there is a small additional memory/performance load. - The
notnulldelegate hides the getting and setting in a separate instance which means anything that works with the field, for example Java DI tools, will not work with it. -
lateinitdoesn’t work with primitive types (Int, Char, Boolean etc…) as we saw above. -
lateinitonly works withvarand notval. - when using
lateinityou gain access to the.isInitializedmethod which you can use to check if it was initialized.