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

[Jonathan Gibbons]

On Thu, 7 Jul 2022 00:01:56 GMT, Jonathan Gibbons <jjg 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).
>> 
>> 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