On Thu, 2 Jul 2026 17:25:16 GMT, Alan Bateman <[email protected]> wrote:
>> I see your point, but it does start to get clumsy, and as you point out, >> completely future proofing is even more of a challenge, if even possible. >> With your suggestion, the "preview" reference never goes away. Even in JDK >> 35 with value objects being a permanent feature, we'd need to have wording >> indicating that preview features may need to be enabled on the target VM. Do >> we really want that? > > For reference, here are examples from JDK 19 when virtual threads were in > preview. > > https://docs.oracle.com/en/java/javase/19/docs/api/jdk.jdi/com/sun/jdi/ThreadReference.html > https://docs.oracle.com/en/java/javase/19/docs/api/jdk.jdi/com/sun/jdi/StackFrame.html > > (search for "virtual thread" on these pages) > > It avoided prefixing the clarifications with "When preview are enabled ..." > and instead spoke about the feature in the target VM. This worked because the > feature, and the behavior specified, didn't change in second preview or when > it became a permanent feature in JDK 21. I've udpated this to be handled the same way as virtual threads. There are no preview references (virtual threads only did that for new APIs, and we have no new APIs here). The spec simply says "when the object is a value object..." similar to how it says "when the thread is a virtual thread". ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/2611#discussion_r3515287236
