> On 13 Feb 2020, at 18:42, Jonathan Gibbons <jonathan.gibb...@oracle.com>
> wrote:
>
> On 2/13/20 9:32 AM, Pavel Rappo wrote:
>>> On 13 Feb 2020, at 16:00, Jonathan Gibbons <jonathan.gibb...@oracle.com>
>>> wrote:
>>>
>>> On 2/13/20 7:50 AM, Pavel Rappo wrote:
>>>> a. jdk/javadoc/internal/doclets/formats/html/AbstractTreeWriter.java:143
>>>>
>>>> Shouldn't it use equals() instead of `==` in this case? A quick look shows
>>>> a
>>>> surprising number of reference equality checks on
>>>> javax.lang.model.element.Name
>>>> and javax.lang.model.element.Element instances. Why would we need to use
>>>> reference equality on types with explicitly defined equals() and
>>>> hashCode()?
>>> == is correct for Name and Symbol/Element
>> Thanks for the clarification.
>>
>> Out of curiosity, why is that? I can see that equals() is currently
>> implemented
>> through reference equality in concrete subtypes of Symbol & Element:
>>
>> public boolean equals(Object obj) {
>> return (this == obj);
>> }
>>
>> Still, those types explicitly define equals(). One would think using it is a
>> must.
>>
>> Given the current implementation (there's only one that I can see) of Name
>> it's
>> even more surprising:
>>
>> /** Is this name equal to other?
>> */
>> @DefinedBy(Api.LANGUAGE_MODEL)
>> public boolean equals(Object other) {
>> if (other instanceof Name)
>> return
>> table == ((Name)other).table && index == ((Name)
>> other).getIndex();
>> else return false;
>> }
>
>
> javac Name objects are javac's version of interned strings; we go to the
> effort of putting them in a unique string table just so that we compare using
> '--'.
>
> For both Name and Symbol/Element, equals and hashCode are defined so that you
> can put them in a collection if you need to, but it is still expected that
> you can/will use referential equality when possible for performance reasons.
> And yes, that impl of .equals does look curious. FWIW, there are two impl of
> Name; the other one does not provide definitions of .equals and .hashCode.
> Sigh.
Should we file a bug to investigate this further? That design intent (allowing
referential equality) should be documented. Current implementations of
equals/hashCode could then be revisited.
