On Tue, 4 Aug 2026 02:41:13 GMT, Joe Darcy <[email protected]> wrote:
>> 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 pedag... > > 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. What's wrong with my suggestion to change the last fragment to: "each equivalence class only has a single *distinguishable* element." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32158#discussion_r3713806133
