On Mon, 13 Jul 2026 02:28:52 GMT, David Holmes <[email protected]> wrote:
>> It's not a given. JDI does not implement the Java language nor a Java >> Virtual Machine, so it is not beholden to either spec. References to the JLS >> and JVMS (which already exist in the JDI javadoc) are used in places to aid >> in specifying JDI behavior. > > Not sure what "beholden to the spec" actually means in this context, but to > say JDI value object support is "consistent with JLS/JVMS" really doesn't > tell you anything IMO. The main point here is simply that you can obtain an > `ObjectReference` for a value object, just like any identity object. The > only, very important, difference, is that it is a snapshot of the value > object at that point in time. And whilst the value object is immutable, > different ObjectReferences obtained during construction could capture > different initalization states. Your summary is correct. I was just trying to provide more context and understanding. I can take a stab at a more succinct version that makes no spec references. >> I was referring to debuggee side value objects in this case. >> ObjectReferences are identity objects so two ObjectReferences are only "the >> same" if they are literally the same heap objects, just like with any other >> identity object. As noted below, ObjectReferences are considered to be equal >> (Object.equals()) if "==" of the target VM objects evaluates to true. > > Then I don't understand the original sentence - it makes it sound like there > are additional value objects. Did you just mean to state what the value > object identity check is? i.e. >> In particular, two value objects are considered to be the same if they are >> state-wise equivalent (`x == y` has the value true) Yes. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/2639#discussion_r3572688846 PR Review Comment: https://git.openjdk.org/valhalla/pull/2639#discussion_r3572707056
