RFR [15] 8238969: Miscellaneous cleanup

[Jonathan Gibbons]

On 2/13/20 9:32 AM, Pavel Rappo wrote:
>> On 13 Feb 2020, at 16:00, Jonathan Gibbons <jonathan.gibbons at 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.

-- Jon