On Wed, 5 Aug 2026 22:01:04 GMT, Dan Smith <[email protected]> wrote:
>> We need to start with a domain—what is in the set of all instances?—before
>> we can talk about how many instances are in an equivalence class.
>>
>> Echoing Joe's "frame of reference" comment: from one perspective, the domain
>> includes every encoding of an instance in memory. From another, the domain
>> collapses down to only one element for each distinguishable instance of the
>> class.
>>
>> We can expect some/most readers to come at this from the first frame of
>> reference, which is why we softened some of the language in the JEP, etc.,
>> from "the value objects are the same" to "the value objects are
>> indistinguishable". Maybe in your frame of reference's domain, you're
>> counting two different things, but there's no way to tell them apart, so
>> `==` won't try to.
>>
>> There's also an uncomfortable circularity in the second frame of reference,
>> if we use it to explain the equivalence classes of `==`: each set has a
>> single element because, tautologically, if there were two elements in the
>> set, they would be the same. (I'm rusty on this stuff, but I'll gesture
>> vaguely at Gödel's incompleteness theorems. We need some ground truth to
>> build our equivalence classes on top of.)
>>
>> In the first frame of reference, "has only a single distinguishable element"
>> isn't quite saying the right thing. It's more like "all elements in the set
>> are indistinguishable". But we just said that.
>>
>> I don't necessarily mind the phrasing in the PR. But it is a bit wordy, and
>> the old flow of the paragraph just doesn't quite work the way it was
>> intended to anymore. Maybe it would be better to rephrase the whole note,
>> something like:
>>
>>
>> The {@code equals} method for class {@code Object} implements
>> the most discriminating possible equivalence relation on objects;
>> that is, for any non-null reference values {@code x} and
>> {@code y}, this method returns {@code true} if and only
>> if {@code x} and {@code y} are completely indistinguishable
>> ({@code x == y} has the value {@code true}).
>> <p>
>> In other words, under the object equality equivalence relation, each
>> equivalence class only has a single identity object, or a set
>> of value objects that instantiate the same class with the same
>> field values.
>>
>>
>> (I cheated a little by adopting John's "the same" for field values at the
>> end. The more formal way to say it is "with indistinguishable field values",
>> but I think "the same" reads more smoothly. We're not defining `==` here,
>> just reminding readers how it works.)
>
> Edit: if we're looking to this as the definitive word on "indistinguishable",
> I would drop "completely" and italicize "indistinguishable".
>
> But we can link to JLS from the specs. Maybe even better to turn
> "indistinguishable" into a link to 15.21.3? (In value-objects-jls.html today,
> eventually in JLS proper.)
FYI, John and I agreed to address the broader need to define some core concepts
related to identity and == via JDK-8389875.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/32158#discussion_r3738674881
