RFR [15] 8238969: Miscellaneous cleanup

[Jonathan Gibbons]

On 02/17/2020 04:21 AM, Pavel Rappo wrote:
>> 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.
>
>

Maybe. It's probably less important for the javac internal classes, and 
more important for the public APIs involved, so that's Joe for 
javax.lang.model and "us" for com.sun.source.

-- Jon