I have no general objection to this.
I would use it where lazy initialization will provide a clear benefit,
but not as a general replacement for final.
The eventual conclusion of "final means final" - see
https://openjdk.org/jeps/500 - should improve the performance of final
fields
but doesn't provide lazy initialization, however for many fields the
initialization cost is so small that StableValue is not worth it.
But whilst it is still a preview feature (and so not guaranteed to be
100% stable - pun intended),
I would suggest the uses be kept to the most high value cases.
Since it just shipped as a preview feature in JDK 25, I don't know when
it'll be final, but I'd guess JDK 28 as the earliest.
-phil.
On 9/24/25 4:06 PM, Sergey Bylokhov wrote:
Hello,
I am exploring the use of StableValue feature in the java.desktop
module:
https://download.java.net/java/early_access/jdk26/docs/api/java.base/java/lang/StableValue.html
Previously, the java.desktop module used preview features for Scoped
Values, but that option was later removed since that is not in a
preview now:
https://github.com/openjdk/jdk/pull/26765
We have a lot of synchronization issues that might be addressed by the
StableValue API. Can we use it now, or should we keep using the
current public synchronization APIs? or wait?
