On Thu, 2 Jul 2026 07:35:55 GMT, Alan Bateman <[email protected]> wrote:
>> There are 3 places in StackFrame that use apiNote for a section that should >> actually be considered being part of the spec. apiNote should be removed. >> Also, clarify that that we are talking about the target VM running in >> preview mode, not the JDI code. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > src/jdk.jdi/share/classes/com/sun/jdi/StackFrame.java line 102: > >> 100: * <div class="preview-block"> >> 101: * <div class="preview-comment"> >> 102: * When preview features are enabled for the target VM, > > Dropping `@apiNote` is good as this is normative test (not an API note). > > For the preview-block text then I'm wondering about the case where the > debugger/JDI-tool is running on JDK 28 and the target VM is JDK 35. Value > classes and objects should be be permanent feature by then so there is value > classes and objects without needing to enable preview. Having the back end > and front end be different arises a lot in IDEs. > > I don't think it's possible to future proof completely but maybe it could say > something like "If the target VM supports value classes and objects (link to > JEP 401), ..." and add a note that the feature requires enabling preview > features in JDK 28? If this starts your screaming then ignore my comment, it > might be okay to keep it simple for now. 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? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/2611#discussion_r3514521051
