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

[Pavel Rappo]

On Thu, 4 Apr 2024 21:31:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> True, type parameters are not an issue for annotation interface methods, which [are not allowed to have any parameters][], type or otherwise. However, the code that prints annotations for method signatures does not know that and uses `forMember`, which is applicable to any executable member, of annotation or otherwise.
>> 
>> <img width="356" alt="a screenshot from the generated API Documentation for testNewAndDeprecated" src="https://github.com/openjdk/jdk/assets/32523691/fc808159-7f3f-4a2a-bb25-41474c3b5833">
>> 
>> In principle, I could remove that `vmt.getVisibleMembers(VisibleMemberTable.Kind.ANNOTATION_TYPE_MEMBER)` and the annotation member will be caught by the ["safety net"](https://github.com/openjdk/jdk/pull/18519/files#diff-22d9182196ae739a6de9c29801bb3ca788992b0cbf44564b2aeda2018a7b78e1R611-R621).
>> 
>> Since we are here, there's a `forMember` overload used by `AnnotationTypeMemberWriter`, I probably should remove it for consistency. Thoughts?
>> 
>> [are not allowed to have any parameters]: https://docs.oracle.com/javase/specs/jls/se22/html/jls-9.html#jls-9.6.1
>
> 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.

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

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