On Thu, 4 Apr 2024 21:31:03 GMT, Jonathan Gibbons <j...@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
