<p>
Try to imagine using the standard Java API (Collections, JDBC, IO, ...) without Javadoc.
It would be a nightmare, because Javadoc is the only way to understand of the contract of the API.
Documenting API with Javadoc increases the productivity of the developers consuming it.
</p>

<p>The following Javadoc elements are required:</p>
<ul>
  <li>Parameters, using <code>@param parameterName</code>.</li>
  <li>Method return values, using <code>@return</code>.</li>
  <li>Generic types, using <code>@param &lt;T&gt;</code>.</li>
</ul>

<p>The following public methods and constructors are not taken into account by this rule:</p>
<ul>
  <li>Getters and setters.</li>
  <li>Methods with @Override annotation.</li>
  <li>Empty constructors.</li>
  <li>Static constants.</li>
</ul>

<p>The following code snippet illustrates this rule:</p>

<pre>
/**
  * This is a Javadoc comment
  */
public class MyClass&lt;T&gt; implements Runnable {    // Non-Compliant - missing '@param &lt;T&gt;'

  public static final DEFAULT_STATUS = 0;        // Compliant - static constant
  private int status;                            // Compliant - not public

  /**
    * This is a Javadoc comment
    */
  public String message;                         // Compliant - well documented

  public MyClass() {                             // Non-Compliant - missing documentation
    this.status = DEFAULT_STATUS;
  }

  public void setStatus(int status) {            // Compliant - setter
    this.status = status;
  }

  @Override
  public void run() {                            // Compliant - has @Override annotation
  }

  protected void doSomething() {                 // Compliant - not public
  }

  /**
    * @param value ...
    */
  public void doSomething(int value) {           // Compliant
  }

  /**
    */
  public int doSomething(int value) {            // Non-Compliant - missing '@param value' and '@return'
    return value;
  }
}
</pre>