Free AI web copilot to create summaries, insights and extended knowledge, download it at here

Abstract

type must be initialized by the constructor. However, it is often the case that doing so is not convenient. For example, properties can be initialized through dependency injection, or in the setup method of a unit test. In these cases, you cannot supply a non-null initializer in the constructor, but you still want to avoid null checks when referencing the property inside the body of a class. This is precisely the situation <code>lateinit</code> was designed to solve.</p><p id="01cc">While it may seem very ad-hoc to include this as a language feature, it reflects the pragmatic realization of the Kotlin team that every single modern application larger than a small private project uses some sort of unit test framework & dependency-injection framework, the majority of which are based on Java. This means that every single modern application would suffer from this problem and Kotlin would not be compatible with frameworks such as Spring, severely decreasing Kotlin adoption and Java interop. Adding <code>lateinit</code> as a feature allows us to keep the good stuff in Kotlin, while still being realistic about the real world.</p><p id="c2eb">When using Spring, you will most often use <code>lateinit</code> when injecting a dependency differently than via constructor injection:</p> <figure id="6043"> <div> <div> <img class="ratio" src="http://placehold.it/16x9"> <iframe class="" src="https://cdn.embedly.com/widgets/media.html?src=ht

Options

tps%3A%2F%2Fpl.kotl.in%2FnqgLwxBnI&display_name=Kotlin+Playground&url=https%3A%2F%2Fpl.kotl.in%2FnqgLwxBnI&image=https%3A%2F%2Fplay.kotlinlang.org%2Fassets%2Fog-image.png&key=a19fcc184b9711e1b4764040d3dc5c07&type=text%2Fhtml&schema=kotl" allowfullscreen="" frameborder="0" height="300" width="800"> </div> </div> </figure></iframe></div></div></figure><p id="64c4">However, be wary of the above code — it’s <a href="https://readmedium.com/a-spring-boot-field-injection-gotcha-a54e7a82d301">prone to failure, and may or may not work on your system</a>.</p><p id="120c">For more technical information about <code>lateinit</code>, <a href="https://kotlinlang.org/docs/properties.html#late-initialized-properties-and-variables">take a look at the docs</a>.</p><p id="c67a">Go back to <a href="https://readmedium.com/compile-time-constants-38dc1d2443b7">Compile Time Constants</a>, jump to the <a href="https://readmedium.com/table-of-contents-c52573cfa291">Table of Contents</a>, or continue to <a href="https://readmedium.com/inheritance-basics-8d5dc28d326e">Inheritance — Basics</a>.</p><figure id="8ecd"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*biBSB579iezsNvEQ_NMLBg.png"><figcaption><a href="https://www.etnetera.cz/prace-u-nas?utm_source=medium&utm_medium=GabrielShanahan&utm_campaign=KotlinPrimer&utm_content=join-our-team&utm_term=KotlinPrimer#pozice">Join me in Etnetera</a></figcaption></figure></article></body>

Lateinit

An explanation of, and motivation for, lateinit

— — — — — — — — — — — — — — —

THE CURRENT VERSION OF THIS ARTICLE IS PUBLISHED HERE.

— — — — — — — — — — — — — — —

Tags: #KOTLIN FEATURE

This article is part of the Kotlin Primer, an opinionated guide to the Kotlin language, which is indented to help facilitate Kotlin adoption inside Java-centric organizations. It was originally written as an organizational learning resource for Etnetera a.s. and I would like to express my sincere gratitude for their support.

It is recommended to read the Introduction before moving on. Check out the Table of Contents for all articles.

Normally, properties declared as having a non-null type must be initialized by the constructor. However, it is often the case that doing so is not convenient. For example, properties can be initialized through dependency injection, or in the setup method of a unit test. In these cases, you cannot supply a non-null initializer in the constructor, but you still want to avoid null checks when referencing the property inside the body of a class. This is precisely the situation lateinit was designed to solve.

While it may seem very ad-hoc to include this as a language feature, it reflects the pragmatic realization of the Kotlin team that every single modern application larger than a small private project uses some sort of unit test framework & dependency-injection framework, the majority of which are based on Java. This means that every single modern application would suffer from this problem and Kotlin would not be compatible with frameworks such as Spring, severely decreasing Kotlin adoption and Java interop. Adding lateinit as a feature allows us to keep the good stuff in Kotlin, while still being realistic about the real world.

When using Spring, you will most often use lateinit when injecting a dependency differently than via constructor injection:

However, be wary of the above code — it’s prone to failure, and may or may not work on your system.

For more technical information about lateinit, take a look at the docs.

Go back to Compile Time Constants, jump to the Table of Contents, or continue to Inheritance — Basics.