New candidate JEP: 502: Stable Values (Preview)

David Gregory david at dgregory.dev
Thu Feb 27 10:43:59 UTC 2025


Hi Maurizio,

On 21/02/2025 18:42, Maurizio Cimadamore wrote:
> There's different meaning for the word "trusted". If, by that, you 
> mean that fields of type StableValue<X> should be trusted the same way 
> that record components are trusted (e.g. where "final" really means 
> "final"), this is something we can do. I believe the prototype we have 
> today does that to some extent -- but we don't know yet whether that 
> "hack" will be made official :-) 

That's awesome! Does creating a StableValue allocate an object, or is 
StableValue optimised away to some bytecode construct by javac?

The reason that I ask is that I wanted to know whether implementers of 
other JVM languages could use this feature - for example, could we mark 
a field as stable using some access modifier at the bytecode level 
without using the StableValue API?

I watched Per's talk at Devoxx and he suggested that it would be 
difficult to allow fields outside of JDK classes to be marked stable for 
security reasons, so I suspect the answer to this is no?

If not, is this a possibility in the future when "trust" and integrity 
of final fields is more fully fleshed out at the JVM level?

I've written up a gist explaining how this feature might be used by 
functional languages, using AtomicReference as a stand-in for 
StableValue, since the API is pretty similar: 
https://gist.github.com/DavidGregory084/6939b85b6fd3ccfdfc83e05011697ed4

The existing StableValue JEP will work great for me personally as the 
translation between my "data" and the underlying JVM classes is not as 
direct as e.g. Scala's case class or Kotlin's data class, and I'd rather 
it was possible to make more programs stack-safe, even if it requires 
allocating lots of StableValues, but I am developing more of a teaching 
language so performance is not exactly paramount for me!

However, it would be great if everybody could get their hands on 
"stable" - e.g. the "next" field in Scala's List cons cell is an amazing 
candidate for stable as it's only mutated immediately after creation, 
like in List#map:

https://github.com/scala/scala/blob/a2090009c4fc3791b545a257ec6d1431e87cb1f4/src/library/scala/collection/immutable/List.scala#L245

Thanks,

David Gregory



More information about the core-libs-dev mailing list