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.
-- Jon
