RFR [15] 8238969: Miscellaneous cleanup

[Pavel Rappo]

> On 13 Feb 2020, at 18:42, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> 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.

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.