Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

What would be a good alternative to inline Java documentation, i.e. can one have a separate docs file somehow mapped to a java source file?

I have never liked huge comment sections littered in code.

share|improve this question
why would you need this? –  gnat Oct 29 '12 at 13:05
@gnat just personal preference, for a hobby project. –  user117 Oct 29 '12 at 13:08
Kindly enlighten me about what in this question makes it impractical, unreal. I'll appreciate that too. –  user117 Oct 29 '12 at 13:23
it would be great if your question explained what kind of problems you're having with standard javadoc. As currently phrased, it's hard to tell whether there is a problem at all, making attempts to answer the question kind of a guessing game –  gnat Oct 29 '12 at 13:30
The real problem with documenting code in a different file is that it is less likely to get updated. When a function changes, sometimes the documentation is not always updated to exactly match it. If the documentation is moved to a different file, there is now one extra step to making the correct change. It also make it less obvious that the documentation is wrong. You will only see it when you look specifically at the documentation, not when you scroll passed it in the code. –  unholysampler Oct 29 '12 at 13:38

2 Answers 2

up vote 7 down vote accepted

I have been using Javadoc feature of package comments to avoid littering source code with verbose documentation comments:

Package-Level Comments

With Javadoc 1.2, package-level doc comments are available. Each package can have its own package-level doc comment source file that The Javadoc tool will merge into the documentation that it produces. This file is named package.html (and is same name for all packages). This file is kept in the source directory along with all the *.java files. (Do not put the packages.html file in the new doc-files source directory, because those files are only copied to the destination and are not processed.)

The file package.html is an example of a package-level source file for java.text and package-summary.html is the file that the Javadoc tool generates.

The Javadoc tool processes package.html by doing three things...

Using above feature, I had detailed verbose documentation for classes and methods in the package stored separately of code, in a dedicated html file. As for Javadoc comments in java files, I just wrote brief explanations there, adding text like

If needed, refer to package documentation for more details.

One thing I particularly liked about this was that although docs were in the separate file and in a format more convenient for large docs (html), it has been stored close enough to related source code and all the updates in it were automatically picked up during the build.

Starting from Java 1.5, you can alternatively put a package-info.java along with the classes of the package. This file should look like this:

 * Javadoc for your package here
package com.yourpackage;

JLS documentation suggests that this is preferred way:

The following scheme is strongly recommended for file-system-based implementations: The sole annotated package declaration, if it exists, is placed in a source file called package-info.java in the directory containing the source files for the package...

It is recommended that package-info.java, if it is present, take the place of package.html for javadoc and other similar documentation generation systems. If this file is present, the documentation generation tool should look for the package documentation comment immediately preceding the (possibly annotated) package declaration in package-info.java. In this way, package-info.java becomes the sole repository for package-level annotations and documentation. If, in future, it becomes desirable to add any other package-level information, this file should prove a convenient home for this information.

share|improve this answer

Some people say the best way to manage comments is having less comments.

Indeed, comments can be autogenerated boilerplate (eurrgh), they can get out of sync with the code and they can be plainly wrong.

If anybody reads them. Especially if you have "huge comment sections littered in code" ;)

In short, the best way to have comments is keeping them short, clear and have them explain the why. This is done by making your code and unit tests super clear.

One exception to this are exposed interfaces. Your user needs explanations to be able to use your tool/library: you can't ask him to read your code.

Last point, if method/class/pasckage javadoc (see the other answer) is not sufficient, maybe a tool validating the examples of the documentation could be of help. Never used that though.

share|improve this answer
This discusses comment contents, but does not answer the question: what are the alternatives to inline JavaDoc? The accepted answer goes into detail about where to put comments. –  Snowman May 23 at 3:43
The idea is to tackle the problem before it happens. That is, do not litter your code with comments in the first place. Then there are less worries about where to put them. –  bernard paulus May 23 at 10:22

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.