Le format général, extrait de la section @link de la documentation javadoc , est le suivant:
Exemples
Méthode dans la même classe:
/** See also {@link #myMethod(String)}. */
void foo() { ... }
Méthode dans une classe différente, dans le même package ou importée:
/** See also {@link MyOtherClass#myMethod(String)}. */
void foo() { ... }
Méthode dans un package différent et non importé:
/** See also {@link com.mypackage.YetAnotherClass#myMethod(String)}. */
void foo() { ... }
Libellé lié à la méthode, en texte brut plutôt qu'en police de code:
/** See also this {@linkplain #myMethod(String) implementation}. */
void foo() { ... }
Une chaîne d'appels de méthode, comme dans votre question. Nous devons spécifier des étiquettes pour les liens vers des méthodes en dehors de cette classe, ou nous obtenons getFoo().Foo.getBar().Bar.getBaz()
. Mais ces étiquettes peuvent être fragiles; voir "Étiquettes" ci-dessous.
/**
* A convenience method, equivalent to
* {@link #getFoo()}.{@link Foo#getBar() getBar()}.{@link Bar#getBaz() getBaz()}.
* @return baz
*/
public Baz fooBarBaz()
Étiquettes
Le refactoring automatisé peut ne pas affecter les étiquettes. Cela inclut le changement de nom de la méthode, de la classe ou du package; et changer la signature de la méthode.
Par conséquent, ne fournissez une étiquette que si vous souhaitez un texte différent de celui par défaut.
Par exemple, vous pouvez lier du langage humain au code:
/** You can also {@linkplain #getFoo() get the current foo}. */
void setFoo( Foo foo ) { ... }
Ou vous pouvez créer un lien à partir d'un exemple de code avec un texte différent de celui par défaut, comme indiqué ci-dessus sous «Une chaîne d'appels de méthode». Cependant, cela peut être fragile pendant que les API évoluent.
Effacer le type et #membre
Si la signature de méthode inclut des types paramétrés, utilisez l'effacement de ces types dans le javadoc @link. Par exemple:
int bar( Collection<Integer> receiver ) { ... }
/** See also {@link #bar(Collection)}. */
void foo() { ... }