Hi Carl, Thanks a lot for taking the time to try out Stable Values / Lazy Constants and for writing up such a clear use case.
On cycles / “placeholders then fill in”: you’re right that the current Lazy Constant API is intentionally functional: the initializer is supplied up front (typically via a lambda), and we removed the imperative “set later” style APIs (e.g., trySet). That was a deliberate design choice—once we explored the space, we found that “imperative stable semantics” introduce a number of sharp edges (storage efficiency, publication, failure modes, interaction with concurrency, invariants, etc.), and it became clearer that they’re better addressed as a separate capability rather than folded into Lazy Constants. We are still interested in that broader space, but Lazy Constants specifically are not currently intended as a general “two-phase construction” mechanism for object graphs. On the name change: the move from “Stable Values” to “Lazy Constants” is not meant to imply “JLS compile-time constant”; it’s more about emphasizing the model: a single-assignment, lazily-initialized value with strong stability guarantees. On serialization: you also correctly noticed that LazyConstant.of (and even List.ofLazy, and Map.ofLazy) are not Serializable. This is intentional. Beyond the well-known drawbacks of Java serialization in general, stability guarantees don’t compose cleanly with Java serialization in the general case. Supporting serialization would require compromises that would undermine key design goals of the feature, so we’ve opted not to make these constructs serializable. Pragmatic suggestion for your use case today: Use a two-stage approach with a mutable builder, which is then "frozen" into an immutable representation (records can work well here). We really appreciate the feedback—use cases like this are exactly what help us evaluate where the boundaries are and what additional capabilities might be worth pursuing in the future. Best, Per Minborg ________________________________ From: Carl M <[email protected]> Sent: Thursday, March 12, 2026 8:26 AM To: [email protected] <[email protected]> Subject: [External] : Stable Values As Record Components Hi, While trying to implement a program to copy a graph, I ran into an issue. I am using record classes to represents the node of the graph. However, I found out recently that the graph may contain cycles. This presents a problem, because as I build the records of the nodes, I can't create a cycle. This sounds like something Lazy Constants (originally Stable Values) might have helped with. However, looking through the second preview docs, I see that methods `trySet` have been removed, making it impossible to construct the nodes with place holders, and then fill them in later. Additionally, the change in name "Stable Values" to "Lazy Constants" implies they are closer to constants (in the JLS sense) than final variables. I think this loss of API surface and name change subtly excludes my use case, sadly. Secondly, the reason I wanted to make a copy of the graph was to ensure that the nodes would be serializable. Serialization is better defined for record classes, so I prefer to use them over regular classes. I saw in the documentation that. Lazy Constants will not be Serializable, which further limits my use of them. I would like to ask that a fully set Lazy Constant be considered Serializable. The specific use case I have is that I would like to serialize the type of a variable. The reflect `Type` is an interface with several implementations. I am only interested in `Class` and `ParameterizedType`. Since these are interfaces, and I don't control the implementation, I wanted to copy the transitive types reachable from them. I also need to be able to serialize these types. Class is already serializable, and I can make my record node serializable, but only if the components are too. I had hoped that representing the possibly cyclic nature of ParameterizedType's getters would be possible with Stable Values (now Lazy Constants). I would like to ask that the use case of representing graph nodes as record classes, which I believe was originally not possible, be considered as a possibility using Lazy Constants.
