On 02/17/2020 04:21 AM, Pavel Rappo wrote:
On 13 Feb 2020, at 18:42, Jonathan Gibbons <[email protected]> wrote:
On 2/13/20 9:32 AM, Pavel Rappo wrote:
On 13 Feb 2020, at 16:00, Jonathan Gibbons <[email protected]> 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
