RFR: JDK-8288368: simplify code in ValueTaglet, remove redundant code

[Jonathan Gibbons]

On Tue, 5 Jul 2022 10:38:53 GMT, Pavel Rappo <prappo at openjdk.org> 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