RFR: 8325088: Overloads that differ in type parameters may be lost [v4]

[Jonathan Gibbons]

On Thu, 4 Apr 2024 21:52:20 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> If you use `forMember` on an `ExecutableElement` whose enclosing element is an annotation type interface, you know there cannot be any type parameters.
>
> Right, but some accommodation/special-casing for annotations will be there anyway:
> 
>   * "safety net",
>   * `getVisibleMember(VisibleMemberTable.Kind.ANNOTATION_TYPE_MEMBER)`
>   * `e.getEnclosingElement().getKind() == ElementKind.ANNOTATION_TYPE`
> 
> I have no preference, let alone strong opinion on either of those options. If you are concerned with "performance", which I know you might be, we could choose the latter option.

I was not specifically concerned about performance in this case. It was more a case of code clarity/confusion (possibly my confusion).

So I guess the choice is one of:
* a common code path for all executable elements, whatever their container, regardless of whether there may be any risk of a clash of member ids caused by type parameters or anything else
* fast-track some code paths when you know there are no type parameters involved

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18519#discussion_r1552506842