Javadoc is the tool, created at Sun Microsystems and shipped alongside the Java platform from its earliest days in the mid-1990s, that generates API documentation in HTML from the doc comments embedded in Java source code. Oracle’s documentation describes the command precisely: it “parses the declarations and documentation comments in a set of Java source files and produces a corresponding set of HTML pages that describe (by default) the public and protected classes, nested classes, interfaces, constructors, methods, and fields.”
The mechanism is a special comment form, opened with a slash and two asterisks, placed directly above a class, method, or field. Inside that comment, authors write prose plus structured tags such as @param to describe a parameter, @return to describe a return value, @throws to document exceptions, and @see and @link to cross-reference other elements. The javadoc command reads these comments and emits a browsable reference. Documentation thus lives in the source itself, immediately adjacent to the code it explains.
Architecturally, the tool generates its output through a component called a doclet. The default Standard Doclet produces the familiar HTML API documentation, but the doclet interface allowed other backends to be substituted, so the same comment-extraction machinery could drive different output formats. The javadoc command can run over individual source files, whole packages, or entire source trees.
Javadoc’s lasting influence was cultural as much as technical. The official online Java API documentation, which generations of programmers consulted daily, was itself generated by Javadoc, which set a strong expectation that a serious library would ship complete, navigable API reference docs. That expectation propagated outward: Doxygen brought a comparable model to C++ and C, and JSDoc carried the same comment-and-tag style into JavaScript.
By tying documentation to source and making it a build product rather than a separately maintained manuscript, Javadoc was an early, widely adopted example of treating docs the way code is treated. It helped normalize the idea, later articulated as docs-as-code, that reference documentation belongs in version control beside the code and should be regenerated as that code evolves.