Hi Mikhail,
you are correct LazyConstant aims at the 80% use case, which is more
similar to Kotlin's "lazy" keyword.
As stated here:
https://mail.openjdk.org/pipermail/leyden-dev/2025-September/002712.html
> That said, the quest for a more fundamental building block is not
over: we now have a clearer idea on how to expose "stable" access to
regular fields/array elements, using a _new_ var handle access mode.
Initial experiments look indeed promising: such an approach doesn't
require the allocation of intermediate abstractions, and allows clients
to decide if they want to pay for synchronization or not.
In other words, something else (lower level) will appear at some point
in the future to "complete" the API. I believe the VarHandle-based
solution we're exploring should be an even better translation target for
Kotlin, as with the outlined strategy you'd now be in control of whether
you need non-plain access, synchronization, etc.
Maurizio
On 10/11/2025 15:51, Mikhail Vorobev wrote:
Hello Amber Team,
I write to provide a data point from the Kotlin Evolution Team on the
design of LazyConstant (previously StableValue). In Kotlin, there is a
`lateinit var` declaration for a variable that is in an uninitialized
state until it is assigned later during execution, after that it
behaves like a normal variable. In practice, people tend to use such
declarations primarily for variables with stable semantics, e.g. for
injected dependencies or Android View bindings:
class Application {
@Inject lateinit var service: Service
}
class MyActivity : AppCompatActivity() {
lateinit var view: ImageView
override fun onCreate(...) {
view = findViewById(R.id.image)
}
}
These variables are intended to be initialized at most once and never
change after that. To cater to such use cases, we considered
introducing `lateinit val` declaration in some form (possibly just as
a delegate, similar to how lazy is implemented now in Kotlin).
StableValue was a perfect fit for the implementation of `lateinit
val`. On the other hand, LazyConstant could not be used to express
desired semantics (without hacks) due to its limited API: it does not
allow setting the value directly after construction.
From our point of view, the current LazyConstant API, in contrast to
StableValue, does not cover a considerable part of use cases for
variables with stable semantics where they are initialized from values
available later and there is no sensible initializer function that
could be provided beforehand.
Best Regards, Mikhail Vorobev, Kotlin Evolution Team
