To document API properly, must precede every exported class, interface, constructor, method, and field declaration with a doc comment.

Document the serialized form if a class is serializable.

Public classes should not use default constructors because there is no way to provide doc comments for them.

With the exception of methods in classes designed for inheritance, the contract should say what the method does rather than how it does its job.

Should enumerate all of the method's preconditions [things that have to be true] postconditions [things that will be true]. Typically, preconditions -> @throws for unchecked exceptions. Preconditions can be specified along with the affected parameters in their @param tags.

Side effects should be documented.

To describe a method's contract fully use :
@param
@return (unless void)
@throws

By convention, text following @param or @return should be a noun phrase.

Text following @throws should consist of the word 'if', followed by a clause describing the conditions under which exception is thrown.

Phrase or clause following @param, @return, or @throws is not terminated by a period

For methods and constructors, the summary description should be a verb phrase. Use the third person declarative tense(e.g. returns the xxx) rather than the second person imperative(e.g. return the xxx).

For classes, interfaces, and fields, the summary description should be a noun phrase describing the thing represented by an instance of the class/interface/field.

Add a package.info for package level comments.

Whether or not a class or static method is thread safe, you should document its thread safety.

Order of Tags:
@author
@version
@param -> required
@return -> required, other than void and constructors
@exception
@see
@since
@deprecated

HTML tags:
p (for paragraph)
i (italics)
@code
@literal
pre
@implspec
@inheritdoc

References : Effective Java Third edition By Joshua Bloch