On Fri, 8 May 2026 21:59:44 GMT, Serguei Spitsyn <[email protected]> wrote:
>> I _think_ the new invariant here is that a value object must never be >> observed to mutate (because if that happened, it would be in an >> implementation-dependent way, and may not be reproducible). >> >> If that needs to be strongly guaranteed, then you need to guard against >> unexpected but valid bytecode shapes. >> >> If it's not really an invariant, and we're just doing this for user >> convenience, then it makes sense to design for conventional use and not >> worry about non-standard bytecode patterns. >> >> (One way to think about this: how bad would it be if this cloning thing >> didn't happen at all? What would break?) > >> If it's not really an invariant, and we're just doing this for user >> convenience, then it makes sense to design for conventional use and not >> worry about non-standard bytecode patterns. > > I prefer this approach. It is already pretty narrow corner case. If a larval > value object escapes because non-standard bytecode patterns, the user may > experience some inconsistency caused by debugging of a value object > construction. It does not look that we have to add more complexity to support > this kind of non-standard bytecode patterns. I've pushed the spec update I'm suggesting now. Please, let me know if you are okay with it, or not. Dan, thank you a lot for this discussion, questions and considerations! ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/2412#discussion_r3211641876
