Javadoc de errores: @link no puede manejar los genéricos "<>"

Question

Considere un método estático en una clase, que he documentado que el uso de 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) 
    ... 

Con el fin de evitar la duplicación de la descripción en la sobrecargada versiones del método, me gustaría utilizar un 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) 

que da la siguiente advertencia:

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

ASCII 60 es <, que forma parte de la firma del método. Funciona con la tuerca Map, String, String), esta notación no puede distinguir dos tipos diferentes de mapas.

This seems to be a known bug. ¿Existe una buena solución?

Answer 1

Los tipos parametrizados NO forman parte de la firma del método.

Java implementa Generics con Type Erasure. El concept of Type Erasure es que el generic types solo está disponible en tiempo de compilación, momento en el cual se "borra"; lo que significa que están despojados del bytecode de la clase. Por lo tanto, son no accesibles en el tiempo de ejecución y no son parte de la firma del método.

Por lo tanto, no hay ninguna razón real para que sean parte de la firma del enlace Javadoc, porque no se puede sobrecargar dos métodos con los tipos genéricos que están asociados a los mismos tipos primas: no puede haber una ambigüedad sobre los tipos genéricos de la firma de tu fuente

Además, Javadoc admite etiquetas HTML y supongo que esta podría ser otra razón por la que muerde el polvo aquí, pero realmente dudo que la herramienta de procesamiento Javadoc haya sido mal implementada.

Answer 2

similares a solución David Conrad, se puede usar la firma por completo como una descripción de enlace, utilizando la sintaxis:

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

Recuerde escapar < y >. Por ejemplo:

{@link #parse(Map, String, String) parse(Map<String, String>, String, String)} 

Answer 3

puede que no sea lo que estás buscando, pero he aprendido a vivir con algo así como * @return Lista {@ link} {@ link de RfRequestSummaryDto}