朋友你好，用使用 javadoc 标记可以做到。具体说明如下：：

javadoc 标记是插入文档注释中的特殊标记，它们用于标识代码中的特殊引用。javadoc 标记由“@”及其后所跟的标记类型和专用注释引用组成。记住了，三个部分——@、标记类型、专用注释引用。

不过我宁愿把它分成两部分：@ 和标记类型、专用注释引用。虽然 @ 和 标记类型之间有时可以用空格符分隔，但是我宁愿始终将它们紧挨着写，以减少出错机会。

javadoc 标记有如下一些：

标记 用于 作用

@author 对类的说明 标明开发该类模块的作者

@version 对类的说明 标明该类模块的版本

@see 对类、属性、方法的说明 参考转向，也就是相关主题

@param 对方法的说明 对方法中某参数的说明

@return 对方法的说明 对方法返回值的说明

@exception 对方法的说明 对方法可能抛出的异常进行说明

下面详细说明各标记。

1。 @see 的使用

@see 的句法有三种：

@see 类名

@see #方法名或属性名

@see 类名#方法名或属性名

类名，可以根据需要只写出类名 (如 String) 或者写出类全名 (如 ng。

String)。那么什么时候只需要写出类名，什么时候需要写出类全名呢？

如果 java 源文件中的 import 语句包含了的类，可以只写出类名，如果没有包含，则需要写出类全名。 ng 也已经默认被包含了。这和 javac 编译 java 源文件时的规定一样，所以可以简单的用 javac 编译来判断，源程序中 javac 能找到的类，javadoc 也一定能找到；javac 找不到的类，javadoc 也找不到，这就需要使用类全名了。

方法名或者属性名，如果是属性名，则只需要写出属性名即可；如果是方法名，则需要写出方法名以及参数类型，没有参数的方法，需要写出一对括号。如

成员类型 成员名称及参数 @see 句法

属性 number @see number

属性 count @see count

方法 count() @see count()

方法 show(boolean b) @see show(boolean)

方法 main(String[] args) @see main(String[])

有时也可以偷懒：假如上例中，没有 count 这一属性，那么参考方法 count() 就可以简写成 @see count。

不过，为了安全起见，还是写全 @see count() 比较好。

@see 的第二个句法和第三个句法都是转向方法或者属性的参考，它们有什么区别呢？

第二个句法中没有指出类名，则默认为当前类。所以它定义的参考，都转向本类中的属性或者方法。

而第三个句法中指出了类名，则还可以转向其它类的属性或者方法。

关于 @see 标记，我们举个例说明。由于 @see 在对类说明、对属性说明、对方法说明时用法都一样，所以这里只以对类说明为例。

/**

* @see String

* @see ng。

StringBuffer

* @see #str

* @see #str()

* @see #main(String[])

* @see Object#toString()

*/

public class TestJavaDoc {

}

生成的文档的相关部分如下图：

String 和 StringBuffer 都是在 ng 包中，由于这个包是默认导入了的，所以这两个类可以直接写类名，也可以写类全名。

str、str() 为同名属性和方法，所以方法名需要用 () 区分。main 是带参数的方法，所以在 () 中指明了参数类型。toString() 虽然在本类中也有 (从 Object 继承的)，但我们是想参考 Object 类的 toString() 方法，所以使用了 Object#toString()。

奇怪的是，为什么其中只有 str、str() 和 main(String[]) 变成了链接呢？那是因为编译时没有把 ng 包或者 Stirng、StringBuffer、Object 三个类的源文件一起加入编译，所以，生成的文档没有关于那三个类的信息，也就不可以建立链接了。

后面讲解 javadoc 编译命令的时候还会详细说明。

上例中如果去把类中的 str 属性去掉，那么生成的文档又会有什么变化呢？你会发现，原来是 str, str()，而现在变成了 str(), str()，因为 str 属性已经没有了，所以 str 也表示方法 str()。

2。 使用 @author、@version 说明类

这两个标记分别用于指明类的作者和版本。缺省情况下 javadoc 将其忽略，但命令行开关 -author 和 -version 可以修改这个功能，使其包含的信息被输出。这两个标记的句法如下：

@author 作者名

@version 版本号

其中，@author 可以多次使用，以指明多个作者，生成的文档中每个作者之间使用逗号 (,) 隔开。

@version 也可以使用多次，只有第一次有效，生成的文档中只会显示第一次使用 @version 指明的版本号。如下例

/**

* @author Fancy

* @author Bird

* @version Version 1。

00

* @version Version 2。00

*/

public class TestJavaDoc {

}

生成文档的相关部分如图：

从生成文档的图示中可以看出，两个 @author 语句都被编译，在文档中生成了作者列表。

而两个 @version 语句中只有第一句被编译了，只生成了一个版本号。

从图上看，作者列表是以逗号分隔的，如果我想分行显示怎么办？另外，如果我想显示两个以上的版本号又该怎么办？

——我们可以将上述两条 @author 语句合为一句，把两个 @version 语句也合为一句：

@author Fancy

Bird

@version Version 1。

00

Version 2。00

结果如图：

我们这样做即达到了目的，又没有破坏规则。@author 之后的作者名和 @version 之后的版本号都可以是用户自己定义的任何 HTML 格式，所以我们可以使用

标记将其分行显示。

同时，在一个 @version 中指明两个用

分隔的版本号，也没有破坏只显示第一个 @version 内容的规则。

3。 使用 @param、@return 和 @exception 说明方法

这三个标记都是只用于方法的。

@param 描述方法的参数，@return 描述方法的返回值，@exception 描述方法可能抛出的异常。它们的句法如下：

@param 参数名 参数说明

@return 返回值说明

@exception 异常类名 说明

每一个 @param 只能描述方法的一个参数，所以，如果方法需要多个参数，就需要多次使用 @param 来描述。

一个方法中只能用一个 @return，如果文档说明中列了多个 @return，则 javadoc 编译时会发出警告，且只有第一个 @return 在生成的文档中有效。

方法可能抛出的异常应当用 @exception 描述。由于一个方法可能抛出多个异常，所以可以有多个 @exception。

每个 @exception 后面应有简述的异常类名，说明中应指出抛出异常的原因。需要注意的是，异常类名应该根据源文件的 import 语句确定是写出类名还是类全名。 　　示例如下：

public class TestJavaDoc {

/**

* @param n a switch

* @param b excrescent parameter

* @return true or false

* @return excrescent return

* @exception ng。

Exception throw when switch is 1

* @exception NullPointerException throw when parameter n is null

*/

public boolean fun(Integer n) throws Exception {

switch ( Value()) {

case 0:

break;

case 1:

throw new Exception("Test Only");

default:

return false;

}

return true;

}

}

使用 javadoc 编译生成的文档相关部分如下图：

可以看到，上例中 @param b excrescent parameter 一句是多余的，因为参数只是一个 n，并没有一个 b但是 javadoc 编译时并没有检查。

因此，写文档注释时一定要正确匹配参数表与方法中正式参数表的项目。如果方法参数表中的参数是 a，文档中却给出对参数 x 的解释，或者再多出一个参数 i，就会让人摸不着头脑了。@exceptin 也是一样。

上例程序中并没有抛出一个 NullPointerException，但是文档注释中为什么要写上这么一句呢，难道又是为了演示？这不是为了演示描述多余的异常也能通过编译，而是为了说明写异常说明时应考运行时 (RunTime) 异常的可能性。

上例程序中，如果参数 n 是给的一个空值 (null)，那么程序会在运行的时候抛出一个 NullPointerException，因此，在文档注释中添加了对 NullPointerException 的说明。

上例中的 @return 语句有两个，但是根据规则，同一个方法中，只有第一个 @return 有效，其余的会被 javadoc 忽略。

所以生成的文档中没有出现第二个 @return 的描述。

讲到这里，该怎么写文档注释你应该已经清楚了，下面就开始讲解 javadoc 的常用命令。

运行 javadoc -help 可以看到 javadoc 的用法，这里列举常用参数如下：

用法：

javadoc [options] [packagenames] [sourcefiles]

选项：

-public 仅显示 public 类和成员

-protected 显示 protected/public 类和成员 (缺省)

-package 显示 package/protected/public 类和成员

-private 显示所有类和成员

-d 输出文件的目标目录

-version 包含 @version 段

-author 包含 @author 段

-splitindex 将索引分为每个字母对应一个文件

-windowtitle 文档的浏览器窗口标题

javadoc 编译文档时可以给定包列表，也可以给出源程序文件列表。

例如在 CLASSPATH 下有两个包若干类如下：

fancy。Editor

fancy。Test

fancy。editor。ECommand

fancy。editor。EDocument

fancy。editor。

EView

这里有两个包 (fancy 和 fancy。editor) 和 5 个类。那么编译时 (Windows 环境) 可以使用如下 javadoc 命令：

javadoc fancy\Test。java fancy\Editor。

java fancy\editor\ECommand。java fancy\editor\EDocument。java fancy\editor\EView。java

这是给出 java 源文件作为编译参数的方法，注意命令中指出的是文件路径，应该根据实际情况改变。

也可以是给出包名作为编译参数，如：

javadoc fancy fancy。editor

用浏览器打开生成文档的 ml 文件即可发现两种方式编译结果的不同，如下图：

用第二条命令生成的文档被框架分成了三部分：包列表、类列表和类说明。

在包列表中选择了某个包之后，类列表中就会列出该包中的所有类；在类列表中选择了某个类之后，类说明部分就会显示出该类的详细文档。而用第一条命令生成的文档只有两部分，类列表和类说明，没有包列表。这就是两种方式生成文档的最大区别了。

下面再来细说选项。

-public、-protected、-package、-private 四个选项，只需要任选其一即可。它们指定的显示类成员的程度。它们显示的成员多少是一个包含的关系，如下表：

-private (显示所有类和成员)

-package (显示 package/protected/public 类和成员)

-protected (显示 protected/public 类和成员)

-public (仅显示 public 类和成员)

-d 选项允许你定义输出目录。

如果不用 -d 定义输出目录，生成的文档文件会放在当前目录下。-d 选项的用法是

-d 目录名

目录名为必填项，也就是说，如果你使用了 -d 参数，就一定要为它指定一个目录。这个目录必须已经存在了，如果还不存在，请在运行 javadoc 之前创建该目录。

-version 和 -author 用于控制生成文档时是否生成 @version 和 @author 指定的内容。不加这两个参数的情况下，生成的文档中不包含版本和作者信息。

-splitindex 选项将索引分为每个字母对应一个文件。

默认情况下，索引文件只有一个，且该文件中包含所有索引内容。当然生成文档内容不多的时候，这样做非常合适，但是，如果文档内容非常多的时候，这个索引文件将包含非常多的内容，显得过于庞大。使用 -splitindex 会把索引文件按各索引项的第一个字母进行分类，每个字母对应一个文件。

这样，就减轻了一个索引文件的负担。

-windowtitle 选项为文档指定一个标题，该标题会显示在窗口的标题栏上。如果不指定该标题，而默认的文档标题为“生成的文档(无标题)”。该选项的用法是：

-windowtitle 标题

标题是一串没有包含空格的文本，因为空格符是用于分隔各参数的，所以不能包含空格。

同 -d 类似，如果指定了 -windowtitle 选项，则必须指定标题文本。

到此为止，Java 文档和 javadoc 就介绍完了。javadoc 真的能让我们在 Java 注释上做文章——生成开发文档。

Trackback:

。

全部