On Tue, 4 Aug 2026 02:00:43 GMT, John R Rose <[email protected]> wrote:
>> Thanks @liach. >> >> @dansmithcode, please advise on wording here. > > No, this is probably TMI. It is likely that this is a bad place to admit > that the VM might be keeping multiple copies. The reason is that this part > of the documentation is building the programming model, which lies above the > virtual metal. But this talk about multiple-but-the-same values is stuff the > VM manages silently so the programmer doesn’t have to think about it. > > The programmer WANTS to think about "multiple copies of the same value" but > needs to learn NOT to. It’s a matter of trusting a New Thing, which is to > say a transitional, pedagogical problem, not a specification issue. The New > Thing is that object creation used to create distinct objects. But now > object creation (a `new` expression) can recreate already-existing value > objects, which are not distinguishable from each other. It adds no value to > say to the programmer "somebody inside the VM might see distinctions that you > can’t". It DOES add value to say to the programmer "you might think you are > creating many values, but values work like primitives, and those value > creation expressions of yours probably don’t match your mental model for > identity creation expressions." The overlap of behavior (say, with GC load) > can be covered in a centralized place, without scaring the user about these > swarms of indistinguishable objects they can do little or nothing about. > > Putting it another way: If we put implementation-dependent concepts (I mean, > specifically, the admission that there might be multiple stored copies of the > same value) scattered randomly through API documentation, we will confuse > readers with useless information masquerading as useful. And it is useless > to know that a VM implementation *might* (or *might not*) make multiple > copies of a single value. Just as multiple copies of the int 42 are all the > same 42. Not "different objects with state 42". If we don’t teach this > right, we will blunt the effectiveness of value objects, by making peoples > mental models murky. > > Surely, because it’s a New Thing, we must (somewhere) admit that > implementations are allowed to manage multiple copies of the "same" value, > where the bare term "same" – the term "same" taken from the JVMS to document > `acmp` behavior – has been exquisitely sharpened to something like "statewise > equivalent", in some contexts. But, it’s the same value. Period. Unless > you are debugging the VM. > > Once this behavior of values (sameness despite multiple storage) becomes an > Old Thing there will be no pedagogical value to ma... The existing sentence in Object.equals is: "In other words, under the object equality equivalence relation, each equivalence class only has a single element." This is at least misleading -- likely to be misinterpreted by readers -- and, depending on one's chosen frame of reference, incorrect. My goal is to end with a non-misleading and correct, short, replacement statement. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32158#discussion_r3709062121
