{"id":754,"date":"2026-10-05T13:50:00","date_gmt":"2026-10-05T11:50:00","guid":{"rendered":"https:\/\/grindloop.io\/blog\/?p=754"},"modified":"2026-10-05T14:06:04","modified_gmt":"2026-10-05T12:06:04","slug":"non-null-kotlin-property-is-null","status":"publish","type":"post","link":"https:\/\/grindloop.ai\/blog\/non-null-kotlin-property-is-null\/","title":{"rendered":"Why a Non-Null Kotlin Property Is Null When the Base Class Init Calls an Open Function"},"content":{"rendered":"

A non-null Kotlin property is null when the base class init<\/code> calls an overridable function. The subclass overrides that function and reads its own properties. Kotlin runs the base class initialization first. So at that moment, none of the subclass’s fields have been assigned yet. They still hold the JVM default. That is null for objects and 0 for numbers. That includes private val<\/code> constructor parameters. The type says String<\/code>. The field holds null. A second cause keeps the bug quiet. The compiler rejects a direct read of an unassigned property in an initializer. It doesn’t follow that read through a function call. It also emits no null check when a class reads its own field. So the null travels until something dereferences it. The fix is a rule for the base class. Its constructor must never call a member a subclass can override. Start the work from the subclass’s own init<\/code>, after its properties, or from an explicit lifecycle call.<\/p>\n\n

A BaseViewModel that loads data from init crashes its subclass<\/h2>\n\n

The running example is a pattern that shows up in Android codebases and in bug-squash snippets. A BaseViewModel<\/code> wants every screen to load on creation, so it calls an abstract hook from init<\/code>. ProfileViewModel<\/code> implements the hook with its repository and a user ID. To compile it outside Android, ViewModel<\/code> here is a plain stand-in class. Nothing in the bug depends on androidx.lifecycle<\/code>.<\/p>\n\n\n

open class ViewModel \/\/ stand-in for androidx.lifecycle.ViewModel\n\ninterface ProfileRepository { fun load(userId: String): String }\nclass FakeRepo : ProfileRepository { override fun load(userId: String) = \"Profile($userId)\" }\n\nabstract class BaseViewModel : ViewModel() {\n    init {\n        loadInitialData()\n    }\n    protected abstract fun loadInitialData()\n}\n\nclass ProfileViewModel(\n    private val repository: ProfileRepository,\n) : BaseViewModel() {\n    private val userId = \"u-42\"\n    private val history = mutableListOf<String>()\n\n    override fun loadInitialData() {\n        println(\"userId=$userId history=$history repository=$repository\")\n        history += repository.load(userId)\n    }\n}\n\nfun main() {\n    ProfileViewModel(FakeRepo())\n}<\/pre>\n\n\n
Compiled with kotlinc<\/code> 2.4.20 and run on the JVM, it prints one line and then crashes:<\/p>\n\n\n
userId=null history=null repository=null\nException in thread \"main\" java.lang.NullPointerException: Cannot invoke \"ProfileRepository.load(String)\" because \"this.repository\" is null\n\tat ProfileViewModel.loadInitialData(Main.kt:21)\n\tat BaseViewModel.<init>(Main.kt:8)\n\t...<\/pre>\n\n\n
All three properties are non-null types. All three are null. The repository<\/code> case is the confusing one. It was passed in as an argument. That argument wasn’t null. The build printed no warning for either class. The second stack frame is the clue. The override ran inside BaseViewModel.<init><\/code>, the base class constructor.<\/p>\n\n
A non-null Kotlin property is null because the base init runs first<\/h2>\n\n
The Kotlin inheritance docs<\/a> spell out the order. Base class initialization happens first. Only the evaluation of the arguments to the base class constructor comes before it. The derived class’s initialization logic runs after it. The docs then warn about this exact case. The derived class’s properties aren’t initialized while the base constructor runs. The docs say using them from base class initialization “may lead to incorrect behavior or a runtime failure.” That holds for direct reads and for reads through an overridden open<\/code> member.<\/p>\n\n
Walk ProfileViewModel(FakeRepo())<\/code> through that order:<\/p>\n\n
    \n
  1. The JVM allocates the object. Every field starts at its default. References are null. An Int<\/code> would be 0.<\/li>\n
  2. BaseViewModel<\/code>‘s init<\/code> runs and calls loadInitialData()<\/code>. The call dispatches to the override in ProfileViewModel<\/code>, because the object already is a ProfileViewModel<\/code>.<\/li>\n
  3. The override reads userId<\/code>, history<\/code> and repository<\/code>. Nothing has assigned them yet, so it sees three nulls and crashes on repository.load()<\/code>.<\/li>\n
  4. Had it survived, ProfileViewModel<\/code>‘s own initialization would run next. That’s where repository<\/code> gets stored from the argument and userId<\/code> gets \"u-42\"<\/code>.<\/li>\n<\/ol>\n\n
    Step 4 explains the constructor parameter. A private val<\/code> in the primary constructor is a property. Its field is assigned in the subclass’s initialization, like any other property. The argument exists in step 2. The field just doesn’t hold it yet. A string literal doesn’t help either. \"u-42\"<\/code> is a constant. Still, userId<\/code> isn’t a const val<\/code>. Its field gets the value in step 4, like the rest.<\/p>\n\n
    The compiler checks a direct read but not a read through a call<\/h2>\n\n
    Kotlin does guard part of this. If an init<\/code> block reads a property above its declaration, the build fails. With 2.4.20, the error is “variable ‘userId’ must be initialized.” If the same read moves into a function, the check stops:<\/p>\n\n\n
    class Early {\n    init { show() }\n    private val userId = \"u-42\"\n    private fun show() = println(\"init sees userId=$userId\")\n}\n\nfun main() { Early() }<\/pre>\n\n\n\n
    init sees userId=null<\/pre>\n\n\n
    That compiles with no warning. There’s no inheritance in it at all. The check works inside one initializer, line by line. It doesn’t follow calls. An override in a subclass is even further out of its reach. When BaseViewModel<\/code> compiles, the compiler doesn’t know which subclasses will exist.<\/p>\n\n
    Once the null is in the field, nothing stops it at the read. Kotlin trusts its own non-null types when a class reads its own field. So it adds no check there. The null moves on until a call on it fails. In the example, that’s repository.load()<\/code>. A null userId<\/code> passed to a Java method could travel further first. The Kotlin null safety docs<\/a> list this among the few ways to get an NPE in Kotlin. They call it data inconsistency during initialization. One named case is a superclass constructor that calls an open member whose override uses uninitialized state.<\/p>\n\n
    Start the work after construction, from code that knows the order<\/h2>\n\n
    The base class can’t make its subclasses safe to call during its own init<\/code>. So it shouldn’t call them there. The inheritance docs give the same advice. Avoid open<\/code> members in constructors, property initializers and init<\/code> blocks. For the running example, the smallest fix moves the call into the final subclass:<\/p>\n\n\n
    abstract class BaseViewModel : ViewModel()\n\nclass ProfileViewModel(\n    private val repository: ProfileRepository,\n) : BaseViewModel() {\n    private val userId = \"u-42\"\n    private val history = mutableListOf<String>()\n\n    init {\n        loadInitialData()\n    }\n\n    private fun loadInitialData() {\n        history += repository.load(userId)\n        println(\"history=$history\")\n    }\n}\n\nfun main() {\n    ProfileViewModel(FakeRepo())\n}<\/pre>\n\n\n\n
    history=[Profile(u-42)]<\/pre>\n\n\n
    Three details make this version safe.<\/p>\n\n