On Thu, 7 Jul 2022 00:01:56 GMT, Jonathan Gibbons <[email protected]> wrote:
>>> Interestingly, it looks like no implementation of `Element` actually >>> overrides `equals()`, meaning they all inherit the reference based >>> implementation from `java.lang.Object`. I guess this also answers the >>> question why the `elementsEquals` method was necessary at some point in >>> time (methods returning different element instances). >> >> If we disregard the possibility of multiple implementations of >> `javax.lang.model.element.Element` intermixing at runtime, the fact the >> JDK's `Element.equals` does not override `Object.equals` means that >> instances of `Element` are unique. >> >> To me, the need for `Utils.elementsEqual` is still a mystery. The method (as >> well as its sole use) seems to have appeared in cf406deb without much >> justification. That use-site comment could be better: more explanation as to >> why `Element.equals` might not be accurate or a couple of examples where it >> is so would be really good. > > After a heroic effort by various members of the javac team a long time ago, > `Element`s (actually, javac `Symbol`s) have identity and can be compared with > `==`. (Previously, there was a period when elements could not be compared > across rounds of annotation processing, but even that would not apply here, > to javadoc.) I'm prepared to believe the need for `elementsEqual` is just unfinished code and maybe misunderstanding. After all, it was labelled `TODO: investigate`. I also note that `elementsEqual` was highly imperfect, although sufficient to the one use case. It would not have correctly compared executable elements. ------------- PR: https://git.openjdk.org/jdk/pull/9149
