parameter types in @link tag

[Anna Kozlova]

Thanks, Jon!

Anna

On Tue, Jan 18, 2022 at 9:07 PM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> Hi Anna,
>
> The intent is that the names should follow javac usage: either use a
> qualified name or use a simple name that is in scope, such as an imported
> name.
>
> That being said, javadoc does not use pure-javac code for the lookup, and
> there are some allowances made for historical usage.  I could believe there
> are residual bugs in this area, and any resolution would be in favor of
> moving closer to javac rules where possible.
>
> -- Jon
> On 1/17/22 4:36 AM, Anna Kozlova wrote:
>
> Hi all!
>
> I am trying to figure out if the javadoc tool should be ok with a short
> class name as parameter type. Is there any specification on @link tag
> format?
>
> E.g. javadoc for `java.io.File#isDirectory` contains the following "{@link
> java.nio.file.Files#readAttributes(Path,Class,LinkOption[])"
> <%7B at linkjava.nio.file.Files#readAttributes(Path,Class,LinkOption[])>.
> LinkOption
> isn't resolved but the generated html correctly navigates the
> "readAttributes" method. This makes me suspect that the signatures are
> checked by short names only.
> But this leads to the problem with the ambiguity:
> ```class Foo {
>     /**
>
>      * {@link #bar(Bar)}     */    void foo() {}
>     void bar(Foo2.Bar f) {}
>     void bar(Foo1.Bar f) {}
> }class Foo1 {
>     static class Bar {}
> }class Foo2 {
>     static class Bar {}
> }```
>
> Here the link points to the first method as it is written in the class
> "Foo" which looks wrong, or is it ok?
>
> Thank you,
> Anna Kozlova
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/javadoc-dev/attachments/20220118/e3a67570/attachment-0001.htm>