When a method reference in a @link or @see tag includes the method signature, JavaDoc uses the provided signature in the label for the generated link. However, if a non-overloaded method is referenced just by its name, the signature generated by JavaDoc uses fully qualified type names including type arguments for generic types.

This seems counterproductive, since the purpose of the link label is to quickly convey the identity of the linked method. While parameter types are an important part of that, the exact package of parameter types is usually not. In most cases, parameter types are well known and either part of the Java platform or the documented API, so using using fully qualified names adds little value to the user, but makes signatures much more verbose.

In a similar vein, I would also argue that type arguments are mostly not useful in method link labels. They obfuscate the basic method signature, often adding more fully qualified type names in bounded parameters. They also assume a level of understanding of the linked method that goes beyond the purpose of providing a link.

For these reasons, we also decided to use non-qualified parameter types without type parameters in member signatues in the table of content sidebar, which seems to work well in its context. I propose to use the same settings for `@link` and `@see` tags when a method reference does not include the full method signature.

I'm uploading a few screenshots from JDK API docs to illustrate the problems. Note how the `@see` tags from `java.lang.Thread.UncaughtExceptionHandler` display the FQN for its own type, the enclosing type, and `java.lang.Throwable`. The other examples show the combination of FQN and type parameters in `java.util.concurrent.CompletionStage.exceptionallyAsync` and `java.nio.file.spi.FileSystemProvider.newInputStream`.