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