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

[Pavel Rappo]

On Thu, 7 Jul 2022 00:14:12 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

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

> Elements (actually, javac Symbols) have identity and can be compared with `==`.

It's a nice property to have. I see that you have already changed `!=` to `!equals` in 5dcf391, so thanks.

Since `==` used for anything other than primitives and enums causes me to pause and think, I have a few questions for the future.

Is javadoc expected to be able to run with a different implementation of javac? If so, then the javadoc code that uses `==` will be broken, if in that implementation that property of elements does not hold.

If javadoc is not expected to be able to run with another implementation of javac, then this property should be common knowledge. If that property is not written down and easily discoverable, it should be. Also, any use sites should refer to it and/or use `assert e1.equals(e1) == (e1 == e2)` or some such.

Alternatively, using `equals` instead of `==` would remove any doubts. Let the runtime do all the optimizations.

-------------

PR: https://git.openjdk.org/jdk/pull/9149