Or use delegates to inject from Injekt framework:
It can be used as default constructor expressions, as delegates, or as just a function to return a value from the object registry.
Injekt will soon materialize object graphs, and the “lateinit” will be useful then possibly.
Also it would be nice for the Jackson-Jr port to Kotlin. But mostly those are taking a bit different approach that might include “lateinit” but as a lower priority. With M13 they can base decisions on which things are nullable or not, final or can be set later, have default values or not (Java injection and data binding frameworks will not get this right, so they will never really fit well without using Kotlin reflection), and lastly could use “lateinit” when no other path makes sense such as a “val” property not in the constructor and should be injected without a delegate (but why not use a delegate unless your object wasn’t made by you that you are injecting into). So a combination of constructor parameters, setters, and “lateinit” properties.
But these are “going forward” frameworks that assume most your App code is Kotlin, and you “use” Java libraries but the Kotlin is in control, and where Injection and data binding happen. Although our data binder will handle generic Java cases as well. Just not as pretty.