On Tue, 5 Jul 2022 10:38:53 GMT, Pavel Rappo <[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). > >> 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 `Symbols) 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.) ------------- PR: https://git.openjdk.org/jdk/pull/9149
