How to Link to a Method in JavaDoc with @link in Java

By the end of this page, you will understand how JavaDoc method links work, how to reference methods correctly with {@link ...}, and how to write links for methods in the same class, other classes, and overloaded methods. You will also learn why chaining multiple method links usually needs a slightly different approach than normal Java code.

JavaDoc uses inline tags like {@link ...} to create clickable references in generated documentation. These links do not work like normal Java expressions. Instead, they point to documented program elements such as:

• classes
• interfaces
• fields
• constructors
• methods

When linking to a method, JavaDoc expects a reference, not an actual executable method call. That means you write the method name and, when needed, its parameter types.

For example:

{@link #getFoo()}

This means:

• # → a member of the current class
• getFoo() → the method being referenced

If the method belongs to another class, include the class name:

{@link Foo#getBar()}

This matters because JavaDoc is meant to generate navigable documentation, not to evaluate code. So when you want to describe a chain like getFoo().getBar().getBaz(), you are really documenting related methods, not calling them.

A good JavaDoc link improves readability and helps readers jump directly to the relevant API details.

Think of JavaDoc {@link ...} as a map reference, not a function call.

• Normal Java code is like driving to a place.
• JavaDoc {@link ...} is like writing the address in a guidebook.

So this Java code:

getFoo().getBar().getBaz()

actually performs actions.

But this JavaDoc:

{@link #getFoo()}

just points the reader to where getFoo() is documented.

If you want to show a chain of calls in JavaDoc, imagine writing directions in a manual:

• first see getFoo()
• then see getBar()
• then see getBaz()

You are referencing each stop on the path, not executing the trip.

The basic JavaDoc syntax for linking to methods is:

{@link #methodName()}

For a method in another class:

{@link ClassName#methodName()}

For overloaded methods, include parameter types:

{@link #print(String)}
{@link Math#max(int, int)}

Example: method in the same class

/**
 * Returns the user's full name.
 * This is a convenience method that combines {@link #getFirstName()} and {@link #getLastName()}.
 */
public String getFullName() {
    return getFirstName() + " " + getLastName();
}

Here:

• #getFirstName() links to a method in the same class
• #getLastName() links to another method in the same class

Example: method in another class

/**
 * Parses an integer using {@link Integer#parseInt(String)}.
 */
public int parse(String value) {
    return Integer.parseInt(value);
}

Example: your case

A better JavaDoc version would be:

/**
 * Returns the Baz object owned by the Bar object owned by Foo owned by this.
 * A convenience method, equivalent to {@link #getFoo() getFoo()}.{@code getBar()}.{@code getBaz()}.
 * @return baz
 */
public Baz fooBarBaz()

Or, even clearer:

/**
 * Returns the Baz object owned by the Bar object owned by Foo owned by this.
 * Equivalent to calling {@link #getFoo()}, then {@code getBar()}, then {@code getBaz()}.
 * @return baz
 */
public Baz fooBarBaz()

If all three methods are documentable and you want each one linked, you can reference their owning classes explicitly:

/**
 * Equivalent to {@link #getFoo()}, then {@link Foo#getBar()}, then {@link Bar#getBaz()}.
 */

This works because getBar() is a method on Foo, and getBaz() is a method on Bar.

Consider this example:

class OrderService {
    /**
     * Returns the final amount.
     * Equivalent to {@link #getOrder()}, then {@link Order#getInvoice()}, then {@link Invoice#getTotal()}.
     */
    public double getFinalAmount() {
        return getOrder().getInvoice().getTotal();
    }

    public Order getOrder() {
        return new Order();
    }
}

Step by step:

1. {@link #getOrder()}

   • # means the current class, OrderService
   • JavaDoc links to OrderService.getOrder()

2. {@link Order#getInvoice()}

   • Order tells JavaDoc to look in the Order class
   • It links to the getInvoice() method there

3. {@link Invoice#getTotal()}

   • JavaDoc links to the getTotal() method in Invoice

4. These links are rendered as clickable references in the generated documentation

5. None of these links execute code

   • They only point to the related API documentation

That is the key idea: JavaDoc references program elements by name and signature, not by evaluating expressions.

Method links in JavaDoc are useful in real projects whenever one method depends on, wraps, or simplifies another method.

1. Convenience methods

A method may combine several smaller methods:

/**
 * Convenience method that uses {@link #loadConfig()} and {@link #startServer()}.
 */

2. Wrapper APIs

A public method may delegate to another class:

/**
 * Delegates to {@link HttpClient#send(HttpRequest)}.
 */

3. Utility classes

You can point readers to the exact helper method being used:

/**
 * Normalizes input using {@link String#trim()}.
 */

4. Framework or library documentation

Library authors often use JavaDoc links so users can jump between related methods quickly.

5. Deprecated method guidance

A deprecated method often links to the replacement:

/**
 * @deprecated Use {@link #save(User)} instead.
 */

In real codebases, developers usually use JavaDoc links in a few common patterns.

Guarding readers toward the right API

If one method should be used instead of another:

/**
 * Prefer {@link #createConnection()} for automatic configuration.
 */

Describing delegation

A wrapper method often explains where the real work happens:

/**
 * Internally calls {@link Repository#findById(long)}.
 */

Clarifying convenience methods

A method may be a shortcut for a longer sequence:

/**
 * Shortcut for calling {@link #open()}, then {@link #read()}, then {@link #close()}.
 */

Documenting overloads precisely

When multiple methods share the same name, developers include parameter types:

/**
 * See also {@link #log(String)} and {@link #log(String, Throwable)}.
 */

Pairing links with code formatting

In practice, many teams mix {@link ...} and {@code ...}:

• use {@link ...} for clickable documented elements
• use {@code ...} for plain code text or expression snippets

Example:

/**
 * Equivalent to calling {@link #getFoo()} and then {@code getBar()} on the result.
 */

This is often clearer than trying to make every part of a chained expression into a separate link.

1. Forgetting # for methods in the same class

Broken:

{@link getFoo()}

Correct:

{@link #getFoo()}

Why: for members of the current class, JavaDoc expects #methodName().

2. Treating {@link ...} like executable Java code

Broken idea:

{@link #getFoo().getBar().getBaz()}

Why it is wrong:

• JavaDoc cannot evaluate chained method calls inside one link
• a link must point to a single documented element

Correct approach:

{@link #getFoo()}, {@link Foo#getBar()}, {@link Bar#getBaz()}

3. Omitting parameter types for overloaded methods

Broken:

{@link #print()}

This may be ambiguous if there are multiple print methods.

Better:

{@link #print(String)}

4. Using argument names instead of types

Broken:

{@link #save(user)}

Correct:

{@link #save(User)}

JavaDoc uses parameter types, not variable names.

5. Linking every tiny thing

Sometimes too many links hurt readability.

Less readable:

Equivalent to {@link #getFoo()}, then {@link Foo#getBar()}, then {@link Bar#getBaz()}.

Sometimes better:

Equivalent to {@code getFoo().getBar().getBaz()}.

Rule of thumb:

• use {@link ...} when the reader benefits from navigation
• use {@code ...} when you just want to show code text

{@link ...} vs {@code ...}

Use {@link ...} when you want to link to a documented API element.

Use {@code ...} when you want to display code exactly as text.

For your original example, this is often the clearest split:

A convenience method, equivalent to {@code getFoo().getBar().getBaz()}.

Or, if you want some navigation too:

A convenience method, equivalent to {@link #getFoo()} followed by {@code getBar().getBaz()}.

Same-class method vs other-class method

// Method in same class
{@link #getFoo()}

// Method in another class
{@link Foo#getBar()}

// Overloaded method
{@link #print(String)}

// With custom link label
{@link #getFoo() getFoo()}
{@link Integer#parseInt(String) parseInt}

Rules

• Use # for members of the current class
• Use ClassName#methodName() for members of another class
• Include parameter types for overloaded methods
• Use types, not variable names
• A single {@link ...} can only reference one program element
• For plain code expressions, use {@code ...}

Good patterns

/**
 * See {@link #load()}.
 */

/**
 * Delegates to {@link Files#readString(java.nio.file.Path)}.
 */

/**
 * Equivalent to {@code getFoo().getBar().getBaz()}.
 */

Important edge case

This is not valid as one link:

{@link #getFoo().getBar()}

Because JavaDoc links to one element at a time, not chained execution.

How do I link to a method in the same class in JavaDoc?

Use {@link #methodName()}. Example:

{@link #getFoo()}

How do I link to a method in another class?

Use {@link ClassName#methodName()}. Example:

{@link Integer#parseInt(String)}

Can I link to a chained call like getFoo().getBar() in one @link?

No. A JavaDoc link can only point to one documented element at a time. Use multiple links or {@code ...} for the full expression.

How do I link to an overloaded method?

Include the parameter types:

{@link #print(String)}

Should I use @link or @code for method chains?

Usually {@code ...} is better for full expressions like getFoo().getBar().getBaz(). Use {@link ...} when you want clickable navigation to a specific API member.

Can I change the visible text of a JavaDoc link?

Yes. Add a label after the reference:

{@link #getFoo() getFoo()}

Why does my JavaDoc link not resolve?

Common reasons include:

• missing # for same-class methods
• wrong class name
• wrong parameter types
• trying to link to something not visible to JavaDoc
• using an expression instead of a single member reference

• JavaDoc inline tags — {@link ...} is one of several inline documentation tags.
• @see in JavaDoc — useful for adding related links outside the main sentence.
• {@code ...} in JavaDoc — best for showing code snippets and expressions.
• Method overloading in Java — important because overloaded methods affect link syntax.
• Java classes and members — JavaDoc links refer to members such as methods and fields.
• API documentation writing — good JavaDoc is about clarity, navigation, and maintainability.
• Fully qualified class names — sometimes needed when class names are ambiguous.