On Sat, 1 Aug 2026 13:05:02 GMT, Chen Liang <[email protected]> wrote:
>> Another update to Object.equals to better support value classes. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > src/java.base/share/classes/java/lang/Object.java line 182: > >> 180: * constraint as multiple indistinguishable value objects could be >> 181: * constructed, depending on the semantics of the particular value >> 182: * class. > > I would use the term "a single distinguishable element" instead of going into > "multiple value objects" - "multiple" is an impression from the times when > each constructor invocation creates a new distinguishable instance. Value > objects are not necessarily constructed, either - in hotspot, you may load > from a field twice and get two indistinguisable value objects, but another > implementation may deduplicate them, and all these deduplication etc. are not > visible to programs based on our specs. 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 making the Old Thing stand out. (That is why Making the New Thing Stand Out is an antipattern; cf. Gafter’s blog.) In more detail: A value "works like an int". That means ten instances of the number 42, stored at ten different locations in the VM memory, are NOT ten integer values, they are one. A programming model that emphasized the multiplicity of occurrences of 42 would be giving TMI, about implementation details, and would obscure the actual programming model. In the actual programming model, there is just one int value 42, which can be referred to many places. (The wrapper object of type Integer has multiplicity, but values are different specifically on that point!) The programming model needs to read like this, almost everywhere: There is just one FooBar value for each configuration of ForBar’s instance fields. And then there is a footnote, pointing to a package-info file that discusses "fieldwise" at length, in such a way that users can read it once and then forget about it, because it is so reasonable. And THAT forgettable part can have the discussion of "here’s what VM implementations might do, but here’s ALSO why you don’t need to track it". That part can also say, forthrightly, that two `new` expressions can create the SAME value, which is a trick identity objects will never pull. Yes, we need to explain the New Thing somewhere. But not in places like this. When it becomes the Old Thing, this proposed language will be noise and friction. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32158#discussion_r3708921326
