web-dev-qa-db-ja.com

Javadocバグ：@linkはジェネリックス "<>"を処理できません

javadoc を使用してドキュメント化したクラスの静的メソッドについて考えてみます。

/**
 * Description here.
 *
 * @param names       - The parameters of the impression request.
 * @param ids         - An intent object to enrich.
 * @param prefix - A prefix.
 */

public static void parse(Map<String, String> names, String ids, String prefix)
    ...

メソッドのオーバーロードされたバージョンでの説明の重複を避けるために、javadoc @linkを使用したいと思います。

 /**
 * Overloaded version with default prefix.
 * {@link #<parse(Map<String, String>, String, String)> [Text]}
 */

public static void parse(Map<String, String> names, String ids, String prefix)

これは次の警告を出します：

@link:illegal character: "60" in "#parseBtCategories(Map<String, String>, 
                                                     String, String) Text"

ASCII 60は<であり、これはメソッドシグネチャの一部です。これはMap, String, String)ナットで動作します。この表記では2つの異なるタイプのマップを区別できません。

これは既知のバグのようです 良い回避策はありますか？

genericsjavadoc
37
Adam Matan

パラメータ化された型は、メソッドのシグネチャの一部ではありません。

Javaは Generics withType Erasureを実装します。 Type Erasureの概念 は generic types はコンパイル時にのみ使用可能であり、その時点でそれらは「消去」されます。つまり、クラスのバイトコードから削除されます。したがって、これらは実行時にアクセスできませんおよびはメソッドのシグネチャの一部ではありません 。

したがって、同じ生の型に解決されるジェネリック型を持つ2つのメソッドをオーバーロードできないため、それらがJavadocリンクの署名の一部である実際の理由はありません：ソースのシグネチャのジェネリック型に曖昧さはありません。

さらに、JavadocはHTMLタグをサポートしており、これがここでほこりを噛むもう1つの理由であると思いますが、Javadoc処理ツールがこれほどうまく実装されていなかったのではないかと疑っています。

23
haylem

David Conradソリューションと同様に、構文を使用して完全な署名をリンクの説明として使用できます。

{@link class#method(signature) text-to-display}

エスケープすることを忘れないでください<および>。例えば：

 {@link #parse(Map, String, String) parse(Map&lt;String, String&gt;, String, String)}
25
nuoritoveri

それはあなたが探しているものではないかもしれませんが、私は{@link RfRequestSummaryDto}の* @return {@link List}のようなもので生きることを学びました

2
Lawrence