It's the law:

     »Omit @return for methods that return void and for
     constructors; include it for all other methods, even if
     its content is entirely redundant with the method
     description.«

http://java.sun.com/j2se/javadoc/writingdoccomments/index.html

 Also, you should use »gets« instead of »get«:

     »Use 3rd person (descriptive) not 2nd person (prescriptive).
     The description is in 3rd person declarative rather than
     2nd person imperative.
     Gets the label. (preferred)
     Get the label. (avoid)«

http://java.sun.com/j2se/javadoc/writingdoccomments/index.html

 I am using a preprocessor, so I might write

$define RESULT bold version of description

* get RESULT
* @return RESULT

 But I do not actually do this. The preprocessor, would
 be nicer, if one could write:

* get »bold version of description« (=»RESULT«)
* return RESULT

 To get the preprocessor output:

* get bold version of description
* return bold version of description

 Or, even better, a two-pass preprocessor

* get NEXT-RESULT
* return »bold version of description« (=»RESULT«)

I would probably write it as:

    /**
     * Returns bold version of {@code description}.
     */
    private static String bold(String description) {
        return "<b>" + description + "</b>";
    }

Possibly, or even probably, I might add the @param, but I don't think it
helps much. There is form in the Sun API docs for using "Returns..." as
the description and missing out the @return, IIRC.

javadocs do tend to include significant quantities pointlessness.
Pointless documentation is far worse than no documentation at all. It's
like the interactive "help" that gives help on a button labeled X by
saying "This button does X."

Of course removing getters and setters by better use of encapsulation
removes a good chunk of the problem.

Tom Hawtin