Spec-Zone .ru спецификации, руководства, описания, API

Содержание документации

javadoc - Генератор Документации API Java

Генерирует страницы HTML документации API от исходных файлов Java. Этот документ содержит примеры Javadoc™ для Microsoft Windows.

СОДЕРЖАНИЕ

• Резюме
• Описание
  • Обработка Исходных файлов
  • Javadoc Doclets
  • Связанная Документация
  • Терминология
• Исходные файлы
  • Файлы Исходного кода класса
  • Файлы Комментария пакета
  • Файл Комментария краткого обзора
  • Разные Необработанные Файлы
  • Тестовые Файлы и Шаблонные Файлы
• Сгенерированные Файлы
  • Сгенерированные Объявления API
• Комментарии для документации
  • Комментарий Исходного кода
  • Автоматическое Копирование Комментариев Метода
• Теги Javadoc (@tag)
  • Где Теги Могут Использоваться
• Опции (-option)
  • Опции Javadoc
  • Возможности, предоставленные Стандартным Doclet
• Файлы Параметра командной строки

• Выполнение Javadoc
• Простые Примеры
  • Документирование Одного или Более Пакетов
  • Документирование Одного или Более Классов
  • Документирование И Пакеты и Классы
• Пример Реального мира
  • Пример Командной строки
  • Пример make-файла
• Поиск и устранение неисправностей
  • Общий Поиск и устранение неисправностей
  • Ошибки и Предупреждения
• Среда
  • ПУТЬ К КЛАССУ
• Поиск и устранение неисправностей
• См. Также

Справочник

РЕЗЮМЕ

javadoc [ options ] [ packagenames ] [ sourcefilenames ] [ -subpackages pkg1:pkg2:... ] [ @argfiles ]

Параметры могут быть в любом порядке. См. обработку Исходных файлов для деталей о том, как инструмент Javadoc определяет который".java"файлы, чтобы обработать.

options

Параметры командной строки, как определено в этом документе. Чтобы видеть типичное использование javadoc опций, см. Реальный Пример.

packagenames

Серия имен пакетов, разделенных пробелами, такой как java.lang java.lang.reflect java.awt. Следует отдельно определить каждый пакет, который Вы хотите задокументировать. Подстановочные знаки не позволяются; используйте-subpackages для рекурсии. Использование инструмента Javadoc -sourcepath искать эти имена пакета. См. Пример - Документирование Того или Большего количества Пакетов

sourcefilenames

Серия имен исходного файла, разделенных пробелами, каждые из которых могут начаться с пути и содержать подстановочный знак, такой как звездочка (*). Инструмент Javadoc обработает каждый файл, имя которого заканчивается ".java", и чье имя, когда лишено того суффикса, является фактически юридическим именем class (см. информацию об Идентификаторах в Спецификации языка Java). Поэтому, можно назвать файлы с тире (такой как X-Buffer), или другие запрещенные символы, чтобы препятствовать тому, чтобы они были задокументированы. Это полезно для тестовых файлов, и шаблон регистрирует путь, который предшествует, имя исходного файла определяет, где javadoc будет искать файл. (Инструмент Javadoc не использует -sourcepath искать эти имена исходного файла.) Относительные пути относительно текущего каталога, таким образом передавая в Button.java идентично ./Button.java. Имя исходного файла с абсолютным путем и подстановочным знаком, например, /home/src/java/awt/Graphics*.java. См. Пример - Документирование Того или Большего количества Классов. Можно также смешать packagenames и sourcefilenames, как в Пример - Документирующий И Пакеты и Классы

-subpackages pkg1:pkg2:...

Генерирует документацию от исходных файлов в указанных пакетах и рекурсивно в их подпакетах. Альтернатива предоставлению packagenames или sourcefilenames.

@argfiles

Один или более файлов, которые содержат список опций Javadoc, packagenames и sourcefilenames в любом порядке. Подстановочные знаки (*) и -J опции не позволяются в этих файлах.

ОПИСАНИЕ

Можно выполнить инструмент Javadoc на всех пакетах, отдельных исходных файлах, или обоих. Документируя все пакеты, можно или использовать -subpackages для того, чтобы пересечь рекурсивно вниз из высокоуровневого каталога, или передачи в явном списке имен пакета. Документируя отдельные исходные файлы, Вы передаете в списке источника (.java) имена файлов. Примеры даются в конце этого документа. То, как Javadoc обрабатывает исходные файлы, покрывается затем.

Обработка исходных файлов

• Его имя, после снятия изоляции".java"снабдите суффиксом, фактически юридическое имя class (см. Спецификацию языка Java для юридических символов),
• Его путь к каталогу относительно корня исходного дерева является фактически юридическим именем пакета (после того, как, преобразовывая его разделители в точки)
• Его оператор пакета содержит юридическое имя пакета (определенный в предыдущем маркере)

Обрабатывая ссылок - Во время выполнения, инструмент Javadoc автоматически добавляет ссылки перекрестной ссылки к пакету, class и именам элемента, которые документируются как часть того выполнения. Ссылки появляются в нескольких местах:

• Объявления (возвращают типы, типы параметра, типы поля),
• "См. Также" разделы, сгенерированные от @see теги
• Встроенный текст, сгенерированный от {@link} теги
• Имена исключения, сгенерированные от @throws теги
• "Определенный" ссылками к элементам в интерфейсах и "Переопределениях" соединяется с элементами в классах
• Сводные таблицы, перечисляющие пакеты, классы и элементы
• Пакет и деревья наследования class
• Индексирование

Другие детали обработки - инструмент Javadoc представляет один полный документ каждый раз, когда это выполняется; это не может сделать инкрементный, создает - то есть, это не может изменить или непосредственно бестелесные следствия предыдущих выполнений инструмента Javadoc. Однако, это может соединиться со следствиями других выполнений, как только упомянуто.

Как реализовано, инструмент Javadoc требует и полагается на компилятор java, чтобы сделать его задание. Инструмент Javadoc вызывает часть javac скомпилировать объявления, игнорируя задействованную реализацию. Это создает богатое внутреннее представление классов, включая иерархию class, и отношения "использования", затем генерирует HTML от этого. Инструмент Javadoc также поднимает предоставленную пользователем документацию из комментариев для документации в исходном коде.

Фактически, инструмент Javadoc будет работать .java исходные файлы, которые являются чистыми тупиковыми файлами без тел метода. Это означает, что можно записать комментарии для документации и выполнить инструмент Javadoc на ранних стадиях проекта, создавая API, прежде, чем записать реализацию.

Доверие компилятору гарантирует, что вывод HTML соответствует точно фактической реализации, которая может положиться на неявный, а не явный, исходный код. Например, конструкторы по умолчанию документов инструмента Javadoc (см. Спецификацию языка Java), которые присутствуют в .class файлы, но не в исходном коде.

Во многих случаях инструмент Javadoc позволяет Вам генерировать документацию для исходных файлов, код которых является неполным или ошибочным. Это - преимущество, которое позволяет Вам генерировать документацию перед всей отладкой, и поиск и устранение неисправностей делается. Например, согласно Спецификации языка Java, class, который содержит абстрактный метод, должен самостоятельно быть объявлен кратким обзором. Инструмент Javadoc не проверяет на это, и продолжился бы без предупреждения, тогда как javac компилятор останавливается на этой ошибке. Инструмент Javadoc действительно делает некоторую примитивную проверку комментариев документа. Используйте DocCheck doclet, чтобы проверить комментарии документа более тщательно.

Когда инструмент Javadoc создает свою внутреннюю структуру для документации, он загружает все классы, на которые ссылаются. Из-за этого инструмент Javadoc должен быть в состоянии найти все классы, на которые ссылаются, ли классы начальной загрузки, расширения, или пользовательские классы. Для больше об этом, см., Как Классы Находятся. Вообще говоря, классы, которые Вы создаете, должны или быть загружены как расширение или в инструменте Javadoc путь class.

Javadoc Doclets

• Javadoc Doclets
• -doclet параметр командной строки

Связанный Documentation и Doclets

• Улучшения Javadoc для деталей об улучшениях добавили в Javadoc.
• FAQ Javadoc для ответов на общие вопросы, информацию о Javadoc-связанных инструментах, и обходные решения для ошибок.
• Как Записать Комментарии Документа для Javadoc для получения дополнительной информации о соглашениях Sun для того, чтобы записать комментарии для документации.
• Требования для Записи Спецификаций API - Стандартные требования, используемые при записи Java Спецификация Платформы SE. Может быть полезно, пишете ли Вы спецификации API в комментариях для документации исходного файла или в других форматах. Это покрывает требования для пакетов, классов, интерфейсов, полей и методов, чтобы удовлетворить тестируемые утверждения.
• Спецификация Комментария для документации - исходная спецификация на комментариях для документации, Главе 18, Комментариях для документации, в Спецификации языка Java, Первом Выпуске, Джеймсом Гослингом, Биллом Джоем, и Гаем Стилом. (Эта глава была удалена из второго выпуска.)
• DocCheck Doclet - документ Проверок комментирует в исходных файлах и генерирует отчет, перечисляющий ошибки и неисправности, которые это находит. Это - часть Утилит Проверки Документа Sun.
• MIF Doclet - Может автоматизировать генерацию документации API в MIF, FrameMaker и Форматах PDF. MIF является форматом обмена FrameMaker Adobe.

Терминология

сгенерированный документ

Документ, сгенерированный javadoc инструментом из документа, комментирует в исходном коде Java. Значение по умолчанию сгенерированный документ находится в HTML и создается стандартом doclet.

имя

Имя элемента программы, записанного на Языке Java - то есть, имя пакета, class, интерфейса, поля, конструктора или метода. Имя может быть полностью определено, такой как java.lang.String.equals(java.lang.Object), или частично квалифицированный, такой как equals(Object).

задокументированные классы

Классы и интерфейсы, для которых детализированная документация сгенерирована во время выполненного javadoc. Чтобы быть задокументированными, исходные файлы должны быть доступными, их исходные имена файлов или имена пакета нужно передать в javadoc команду, и они не должны быть отфильтрованы их модификатором доступа (общественность, защищенная, частный на пакет или частный). Мы также именуем их как классы, включенные в вывод javadoc, или включенные классы.

включенные классы

Классы и интерфейсы, детали которых документируются во время выполнения инструмента Javadoc. То же самое как задокументированные классы.

исключенные классы

Классы и интерфейсы, детали которых не документируются во время выполнения инструмента Javadoc.

классы, на которые ссылаются,

Классы и интерфейсы, которые явно упоминаются в определении (реализация) или комментарии документа задокументированных классов и интерфейсов. Примеры ссылок включают тип возврата, тип параметра, тип броска, расширенный class, реализованный интерфейс, импортированные классы, классы, используемые в телах метода, @see, {@link}, {@linkplain}, и {@inheritDoc} теги. (Заметьте, что это определение изменилось с тех пор 1.3.), Когда инструмент Javadoc выполняется, он должен загрузить в память все классы, на которые ссылаются, в bootclasspath javadoc и пути к классу. (Инструмент Javadoc печатает "Класс, не найденный" предупреждение для классов, на которые ссылаются, не найденных.) Инструмент Javadoc может получить достаточную информацию из.class файлов, чтобы определить их существование и полностью определенные имена их элементов.

внешние классы, на которые ссылаются,

Классы, на которые ссылаются, документация которых не сгенерирована во время выполненного javadoc. Другими словами эти классы не передают в инструмент Javadoc на командной строке. Ссылки в сгенерированной документации к тем классам, как говорят, являются внешними ссылками или внешними ссылками. Например, если Вы работаете на инструменте Javadoc только java.awt пакет, тогда любой class в java.lang, такой как Object, внешний class, на который ссылаются. Внешние классы, на которые ссылаются, могут быть соединены с использованием -link и -linkoffline опции. Важное свойство внешнего class, на который ссылаются, - то, что его исходные комментарии обычно не доступны выполненному Javadoc. В этом случае эти комментарии не могут быть наследованы.

ИСХОДНЫЕ ФАЙЛЫ

Файлы Исходного кода класса

Файлы Комментария пакета

Чтобы создать пакет комментируют файл, у Вас есть выбор двух файлов поместить Ваши комментарии:

• package-info.java - Может содержать объявление пакета, аннотации пакета, комментарии пакета и теги Javadoc. Этот файл обычно предпочитается package.html.
• package.html - Может содержать только комментарии пакета и теги Javadoc, никакие аннотации пакета.

У пакета может быть сингл package.html файл или сингл package-info.java файл, но не оба. Поместите любой файл в каталог пакета в исходном дереве наряду с Вашим .java файлы.

package-info.java Этот файл может содержать комментарий пакета следующей структуры - комментарий помещается перед объявлением пакета:

Файл: java/applet/package-info.java

/**
 * Provides the classes necessary to create an  
 * applet and the classes an applet uses 
 * to communicate with its applet context.
 * <p>
 * The applet framework involves two entities:
 * the applet and the applet context.
 * An applet is an embeddable window (see the
 * {@link java.awt.Panel} class) with a few extra
 * methods that the applet context can use to 
 * initialize, start, and stop the applet.
 *
 * @since 1.0
 * @see java.awt
 */
package java.lang.applet;

Отметьте что в то время как разделители комментария /** и /* должен присутствовать, ведущие звездочки на промежуточных строках могут быть опущены. package.html - Этот файл может содержать комментарий пакета следующей структуры - комментарий помещается в <body> элемент:

Файл: java/applet/package.html

<HTML>
<BODY>
Provides the classes necessary to create an applet and the 
classes an applet uses to communicate with its applet context.
<p>
The applet framework involves two entities: the applet
and the applet context. An applet is an embeddable
window (see the {@link java.awt.Panel} class) with a
few extra methods that the applet context can use to
initialize, start, and stop the applet. 

@since 1.0 
@see java.awt
</BODY>
</HTML>

Заметьте, что это - только нормальный файл HTML и не включает объявление пакета. Контент файла комментария пакета пишется в HTML, как все другие комментарии, с одним исключением: комментарий для документации не должен включать разделители комментария /** и */ или ведущие звездочки. При записи комментария следует сделать первое предложение сводкой о пакете, и не поместить title или любой другой текст между <body> и первое предложение. Можно включать теги пакета; как с любым комментарием для документации, все метки блока должны появиться после основного описания. Если Вы добавляете a @see тег в пакете комментирует файл, у него должно быть полностью определенное имя. Для получения дополнительной информации см. пример package.html.

Обрабатывая пакета комментирует файл - Когда инструмент Javadoc будет работать, это будет автоматически искать файл комментария пакета; если найдено, инструмент Javadoc делает следующее:

• Копирует комментарий для того, чтобы обработать. (Для package.html, копии весь контент между <body> и </body> HTML-тэги. Можно включать a <head> раздел, чтобы поместить a <title>, оператор авторского права исходного файла, или другая информация, но ни один из них не появится в сгенерированной документации.)
• Процессы любые теги пакета, которые присутствуют.
• Вставляет обработанный текст у основания сводной страницы пакета, которую он генерирует, как показано в Сводке Пакета.
• Копирует первое предложение комментария пакета к вершине сводной страницы пакета. Это также добавляет имя пакета и это первое предложение к списку пакетов на странице краткого обзора, как показано в Сводке Краткого обзора. Конец предложения определяется теми же самыми правилами, используемыми для конца первого предложения class и элемента основные описания.

Файл Комментария краткого обзора

Чтобы создать краткий обзор комментируют файл, можно назвать файл чем-либо, что Вы хотите, обычно overview.html и поместите это куда угодно, обычно на верхнем уровне исходного дерева. Например, если исходные файлы для java.applet пакет содержится в C:\user\src\java\applet каталог, Вы могли создать файл комментария краткого обзора в C:\user\src\overview.html.

Заметьте, что у Вас могут быть многократные файлы комментария краткого обзора для того же самого набора исходных файлов, в случае, если Вы хотите выполнить javadoc многократно на различных наборах пакетов. Например, Вы могли выполнить javadoc однажды с - частный за внутреннюю документацию и снова без той опции для общедоступной документации. В этом случае Вы могли описать документацию как общедоступную или внутреннюю в первом предложении каждого файла комментария краткого обзора.

Контент файла комментария краткого обзора является одним большим комментарием для документации, записанным в HTML, как файл комментария пакета, описанный ранее. См. то описание для деталей. Чтобы повторить, при записи комментария, следует сделать первое предложение сводкой о приложении или наборе пакетов, и не поместить title или любой другой текст между <body> и первое предложение. Можно включать теги краткого обзора; как с любым комментарием для документации, всеми тегами кроме встроенных тегов, такой как {@link}, должен появиться после основного описания. Если Вы добавляете a @see тег, у этого должно быть полностью определенное имя.

Когда Вы выполняете инструмент Javadoc, Вы определяете, что краткий обзор комментирует имя файла с - опция краткого обзора. Файл тогда обрабатывается подобный тому из файла комментария пакета.

• Копии весь контент между <body> и </body> теги для того, чтобы обработать.
• Процессы любые теги краткого обзора, которые присутствуют.
• Вставляет обработанный текст у основания страницы краткого обзора, которую он генерирует, как показано в Сводке Краткого обзора.
• Копирует первое предложение комментария краткого обзора к вершине сводной страницы краткого обзора.

Разные Необработанные Файлы

Чтобы включать необработанные файлы, поместите их в вызванный каталог doc-files который может быть подкаталогом любого каталога пакета, который содержит исходные файлы. У Вас может быть один такой подкаталог для каждого пакета. Вы могли бы включать изображения, пример кода, исходные файлы.class файлы, апплеты и файлы HTML. Например, если Вы хотите включать изображение кнопки button.gif в java.awt.Button Документация class, Вы помещаете тот файл в /home/user/src/java/awt/doc-files/ каталог. Заметьте doc-files каталог не должен быть расположен в /home/user/src/java/doc-files потому что java не пакет - то есть, он непосредственно не содержит исходных файлов.

Все ссылки к этим необработанным файлам должны быть трудно кодированы, потому что инструмент Javadoc не смотрит на файлы - он просто копирует каталог и все его содержание месту назначения. Например, ссылка в Button.java комментарий документа мог бы быть похожим:

    /**
     * This button looks like this:
     * <img src="doc-files/Button.gif">
     */

Тестовые Файлы и Шаблонные Файлы

Если Вы выполняете инструмент Javadoc, явно передавая в отдельных исходных именах файлов, можно сознательно опустить тест и обрабатываете файлы по шаблону, и препятствуйте тому, чтобы они были обработаны. Однако, если Вы передаете на имена пакета или подстановочные знаки, Вы должны следовать за определенными правилами гарантировать эти тестовые файлы и обрабатываете файлы по шаблону, не обрабатываются.

Тестовые файлы отличаются от шаблонных файлов в этом, прежний - юридические, компилируемые исходные файлы, в то время как последние не, но могут закончиться ".java".

Тестовые файлы - Часто разработчики хотят поместить компилируемые, выполнимые тестовые файлы для данного пакета в том же самом каталоге как исходные файлы для того пакета. Но они хотят, чтобы тестовые файлы принадлежали пакету кроме пакета исходного файла, такого как неназванный пакет (таким образом, у тестовых файлов нет никакого оператора пакета или различного оператора пакета из источника). В этом сценарии, когда источник документируется, определяя его имя пакета, определенное на командной строке, тестовые файлы вызовут предупреждения или ошибки. Вы должны поместить такие тестовые файлы в подкаталог. Например, если Вы хотите добавить тестовые файлы для исходных файлов в com.package1, поместите их в подкаталог, который был бы недопустимым именем пакета (потому что это содержит дефис):

    com/package1/test-files/

Если Ваши тестовые файлы содержат комментарии документа, можно установить отдельное выполнение инструмента Javadoc, чтобы произвести документацию тестовых файлов, передавая в их тестовых исходных именах файлов с подстановочными знаками, такой как com/package1/test-files/*.java.

Шаблоны для исходных файлов - у Шаблонных файлов есть имена, которые часто заканчиваются в ".java" и не являются компилируемыми. Если у Вас есть шаблон для исходного файла, который Вы хотите сохранить в исходном каталоге, можно назвать это с тире (такой как Buffer-Template.java), или любой другой недопустимый символ Java, чтобы препятствовать тому, чтобы это было обработано. Это полагается на факт, что инструмент Javadoc только обработает исходные файлы, имя которых, когда лишено суффикса ".java", является фактически юридическим именем class (см. информацию об Идентификаторах в Спецификации языка Java).

СГЕНЕРИРОВАННЫЕ ФАЙЛЫ

Основные Страницы Контента

• Один class или страница интерфейса (имя класса.html) для каждого class или интерфейса это документирует.
• Одна страница пакета (package-summary.html) для каждого пакета это документирует. Инструмент Javadoc будет включать любой текст HTML, обеспеченный в названный файл package.html или package-info.java в каталоге пакета исходного дерева.
• Одна страница краткого обзора (overview-summary.html) для всего набора пакетов. Это - первая полоса сгенерированного документа. Инструмент Javadoc будет включать любой текст HTML, обеспеченный в файл, определенный с -overview опция. Отметьте, что этот файл создается, только если Вы передаете в javadoc два или больше имени пакета. Для дальнейшего объяснения см. Фреймы HTML.)

Страницы перекрестной ссылки

• Одна страница иерархии class для всего набора пакетов (overview-tree.html). Чтобы просмотреть это, щелкните "по Краткому обзору" в панели навигации, затем щелкните "по Дереву".
• Одна страница иерархии class для каждого пакета (package-tree.html) Чтобы просмотреть это, пойдите в определенный пакет, class или страницу интерфейса; щелкните по "Tree", чтобы вывести на экран иерархию для того пакета.
• Одна страница "использования" для каждого пакета (package-use.html) и отдельный для каждого class и интерфейса (class-use/имя класса.html). Эта страница описывает то, что упаковывает, классы, методы, конструкторы и поля используют любую часть данного class, интерфейса или пакета. Учитывая class или интерфейс A, его страница "использования" включает подклассы A, поля, объявленные как A, методы, которые возвращают A, и методы и конструкторов с параметрами типа A. Можно получить доступ к этой странице первым движением к пакету, class или интерфейсу, затем щелкая по ссылке "Использования" в панели навигации.
• Осуждаемая страница API (deprecated-list.html) перечисление всех осуждаемых имен. (Осуждаемое имя не рекомендуется для использования, обычно из-за улучшений, и заменяющее имя обычно дается. Осуждаемые API могут быть удалены в будущих реализациях.)
• Постоянная страница значений полей (constant-values.html) для значений статических полей.
• Сериализированная страница формы (serialized-form.html) для информации о сериализуемых и externalizable классах. У каждого такого class есть описание его полей сериализации и методов. Эта информация представляет интерес для переконструкторов, не разработчикам, использующим API. В то время как нет никакой ссылки в панели навигации, можно добраться до этой информации, идя к любому, сериализировал class, и щелчок "Сериализированная Форма" в "Видит также" раздел комментария class. Стандарт doclet автоматически генерирует сериализированную страницу формы: любой class (общедоступный или непубличный), который реализует Сериализуемый, включается, наряду с readObject и writeObject методы, поля, которые сериализируются, и комментарии документа от @serial, @serialField, и @serialData теги. Общедоступные сериализуемые классы могут быть исключены, отмечая их (или их пакет) с @serial exclude, и частные на пакет сериализуемые классы могут быть включены, отмечая их (или их пакет) с @serial include. С 1.4, можно генерировать полную сериализированную форму для общедоступных и частных классов, работая javadoc, не определяя -private опция.
• Индексирование (index-*.html) из всего class, интерфейса, конструктора, имен полей и имен методов, в алфавитном порядке расположенных. Это интернационализируется для Unicode и может быть сгенерировано как единственный файл или как отдельный файл для каждого начального символа (такого как A-Z для английского языка).

Файлы поддержки

• Страница справки (help-doc.html) это описывает панель навигации и вышеупомянутые страницы. Можно обеспечить свой собственный справочный файл, чтобы переопределить использование значения по умолчанию -helpfile.
• Один index.html файл, который создает фреймы HTML для дисплея. Это - файл, который Вы загружаете, чтобы вывести на экран первую полосу с фреймами. Этот сам файл не содержит текстового контента.
• Несколько файлов фрейма (*-frame.html) содержа списки пакетов, классов и интерфейсов, используемых, когда фреймы HTML выводятся на экран.
• Файл списка пакета (package-list), используемый -link и -linkoffline опции. Это - текстовый файл, не HTML, и не достижимо через любые ссылки.
• Файл таблицы стилей (stylesheet.css) это управляет ограниченным количеством цвета, семейства шрифтов, размера шрифта, стиля шрифта и располагающий на сгенерированных страницах.
• Каталог файлов документа, который содержит любое изображение, пример, исходный код или другие файлы, которые Вы хотите скопированный в целевой каталог. Эти файлы не обрабатываются инструментом Javadoc никаким способом - то есть, любые теги javadoc в них будут проигнорированы. Этот каталог не сгенерирован, если он не существует в исходном дереве.

Фреймы HTML

Инструмент Javadoc генерирует или два или три фрейма HTML, как показано в числе ниже. Это создает минимальное необходимое число фреймов, опуская список пакетов, если есть только один пакет (или никакие пакеты). Таким образом, когда Вы передадите единственное имя пакета или исходные файлы (*.java) принадлежащий единственному пакету как параметры в javadoc команду, это создаст только один фрейм (C) в левом столбце - список классов. Когда Вы передаете в javadoc два или больше имени пакета, он создает третий фрейм (P) перечисляющий все пакеты, так же как страницу краткого обзора (Деталь). У этой страницы краткого обзора есть имя файла overview-summary.html. Таким образом этот файл создается, только если Вы передаете на два или больше имени пакета. Можно обойти фреймы, не щелкая по "Никаким Фреймам" ссылка или входя в overview-summary.html.

Если Вы незнакомы с фреймами HTML, следует знать, что фреймы могут сфокусироваться для печати и прокрутки. Чтобы дать фокус фрейма, щелкните по этому. Затем на многих браузерах клавиши со стрелками и ключи страницы прокрутят тот фрейм, и команда меню печати напечатает его.

Загрузите один из следующих двух файлов как начальная страница в зависимости от того, хотите ли Вы фреймы HTML или нет:

• index.html (для фреймов)
• overview-summary.html (ни для каких фреймов)

Сгенерированный class и файлы интерфейса организуются в той же самой иерархии каталогов, что исходные файлы Java и файлы class организуются. Эта структура является одним каталогом на подпакет.

Например, документ сгенерирован для class java.applet.Applet class был бы расположен в java\applet\Applet.html. Файловая структура для java.applet пакета следует, учитывая, что целевой каталог называют apidocs. Все файлы, которые содержат слово "фрейм", появляются в верхних левых или нижних левых фреймах, как отмечено. Все другие файлы HTML появляются в правом фрейме.

ОТМЕТЬТЕ: Каталоги показывают полужирным. Звездочки (*) укажите на файлы и каталоги, которые опускаются, когда параметрами javadoc являются исходные имена файлов (*.java), а не имена пакета. Также, когда параметрами являются исходные имена файлов, package-list создается, но пуст. Каталог файлов документа не будет создаваться в месте назначения, если он не будет существовать в исходном дереве.

apidocs                             Top directory
   index.html                       Initial page that sets up HTML frames
 * overview-summary.html            Lists all packages with first sentence summaries
   overview-tree.html               Lists class hierarchy for all packages
   deprecated-list.html             Lists deprecated API for all packages
   constant-values.html             Lists values of static fields for all packages
   serialized-form.html             Lists serialized form for all packages
 * overview-frame.html              Lists all packages, used in upper-left frame
   allclasses-frame.html            Lists all classes for all packages, used in lower-left frame
   help-doc.html                    Lists user help for how these pages are organized
   index-all.html                   Default index created without -splitindex option
   index-files                      Directory created with -splitindex option
       index-<number>.html          Index files created with -splitindex option
   package-list                     Lists package names, used only for resolving external refs
   stylesheet.css                   HTML style sheet for defining fonts, colors and positions
   java                             Package directory
       applet                       Subpackage directory
            Applet.html             Page for Applet class
            AppletContext.html      Page for AppletContext interface
            AppletStub.html         Page for AppletStub interface
            AudioClip.html          Page for AudioClip interface
          * package-summary.html    Lists classes with first sentence summaries for this package
          * package-frame.html      Lists classes in this package, used in lower left-hand frame
          * package-tree.html       Lists class hierarchy for this package
            package-use             Lists where this package is used
            doc-files               Directory holding image and example files
            class-use               Directory holding pages API is used
                Applet.html         Page for uses of Applet class
                AppletContext.html  Page for uses of AppletContext interface
                AppletStub.html     Page for uses of AppletStub interface
                AudioClip.html      Page for uses of AudioClip interface
   src-html                         Source code directory
       java                         Package directory
           applet                   Subpackage directory
                Applet.html         Page for Applet source code
                AppletContext.html  Page for AppletContext source code
                AppletStub.html     Page for AppletStub source code
                AudioClip.html      Page for AudioClip source code

Сгенерированные Объявления API

public final class Boolean
extends Object
implements Serializable

и объявление для Boolean.valueOfметод:

public static Boolean valueOf(String s)

Инструмент Javadoc может включать модификаторы public, protected, private, abstract, final, static, transient, и volatile, но нет synchronized или native. Эти последние два модификатора считают деталью реализации и не частью спецификации API.

Вместо того, чтобы полагаться на ключевое слово synchronized, API должны задокументировать свою семантику параллелизма в основном описании комментария, как в "сингле Enumeration не может использоваться многократными потоками одновременно". Документ не должен описать, как достигнуть их семантика. Как другой пример, в то время как Hashtable должно быть ориентировано на многопотоковое исполнение, нет никакой причины определить, что мы достигаем этого, синхронизируя все ее экспортируемые методы. Мы должны зарезервировать право синхронизироваться внутренне на уровне блока, таким образом предлагая более высокий параллелизм.

КОММЕНТАРИИ ДЛЯ ДОКУМЕНТАЦИИ

Комментарий Исходного кода

/**
 * This is the typical format of a simple documentation comment
 * that spans two lines.
 */

/** This comment takes up only one line. */

Частая ошибка состоит в том, чтобы поместить import оператор между class комментирует и объявление class. Избегите этого, поскольку инструмент Javadoc проигнорирует комментарий class.

   /**
    * This is the class comment for the class Whatever.
    */

    import com.sun;   // MISTAKE - Important not to put import statement here

    public class Whatever {
    }

/**
 * This sentence would hold the main description for this doc comment.
 * @see java.lang.Object
 */

/**
 * @deprecated  As of JDK 1.1, replaced by {@link #setBounds(int,int,int,int)}
 */

Комментарии пишутся в HTML - текст должен быть записан в HTML, в котором они должны использовать объекты HTML и могут использовать HTML-тэги. Можно использовать, какой бы ни версия HTML Ваш браузер поддерживает; мы записали стандарт doclet, чтобы генерировать HTML 3.2-совместимый код в другом месте (за пределами комментариев для документации) с включением каскадных таблиц стилей и фреймов. (Мы снабжаем каждый сгенерированный файл предисловием с "HTML 4.0" из-за наборов фрейма.)

Например, объекты для меньше (<) и больше - чем (>) символы должны быть записаны < и >. Аналогично, амперсанд (&) должен быть записан &. Полужирный HTML-тэг <b> показывается в следующем примере.

Вот комментарий документа:

/**
 * This is a <b>doc</b> comment.
 * @see java.lang.Object
 */

Ведущие звездочки - Когда javadoc анализирует комментарий документа, ведущая звездочка (*) символы на каждой строке отбрасываются; пробелы и вкладки, предшествующие начальной звездочке (*) символы также отбрасываются. Запускаясь с 1.4, если Вы опускаете ведущую звездочку на строке, ведущий пробел больше не удаляется. Это позволяет Вам вставить примеры кода непосредственно в комментарий документа внутри a <PRE> тег, и его добавление отступа будут соблюдать. Пробелы обычно интерпретируются браузерами более однородно чем вкладки. Добавление отступа относительно левого поля (а не разделитель /** или <PRE> тег).

Первое предложение - первое предложение каждого комментария документа должно быть сводным предложением, содержа краткое, но полное описание объявленного объекта. Это предложение заканчивается в первый период, который сопровождается пробелом, вкладкой, или разделителем строки, или в первой метке блока. Инструмент Javadoc копирует это первое предложение в задействованную сводку наверху страницы HTML.

Объявление с многократными полями - Java позволяет объявлять многократные поля в единственном операторе, но у этого оператора может быть только один комментарий для документации, который копируется для всех полей. Поэтому, если Вы хотите отдельные комментарии для документации для каждого поля, следует объявить каждое поле в отдельном операторе. Например, следующий комментарий для документации не имеет смысла, записанного как единственное объявление, и был бы лучше обработан как два объявления:

/**
 * The horizontal and vertical distances of point (x,y)
 */
public int x, y;      // Avoid this

public int x

Горизонталь и вертикальные расстояния точки (x, y)

public int y

Горизонталь и вертикальные расстояния точки (x, y)

Автоматическое Копирование Комментариев Метода

• Автоматически наследуйте комментарий, чтобы заполнить недостающий текст - Когда основное описание, или @return, @param или @throws тег отсутствует в комментарии метода, инструмент Javadoc копирует соответствующее основное описание или комментарий тега от метода, который это переопределяет или реализации (если любой) согласно алгоритму ниже.

  Более определенно, когда a @param тег для определенного параметра отсутствует, тогда комментарий для того параметра копируется с метода далее иерархия наследования. Когда a @throws тег для определенного исключения отсутствует, @throws тег копируется, только если то исключение объявляется.

  Это поведение контрастирует с версией 1.3 и ранее, где присутствие любого основного описания или тега препятствовало бы тому, чтобы все комментарии были наследованы.

• Явно наследуйте комментарий с {@inheritDoc}, тег - Вставляет встроенный тег {@inheritDoc} в методе основное описание или @return, @param или @throws комментарий тега – соответствующий наследованный основной комментарий описания или тега копируется в то пятно.

Исходный файл для наследованного метода должен только быть на пути, определенном-sourcepath для комментария документа, чтобы фактически быть доступным копии. Ни в class, ни в его пакете нельзя передать на командной строке. Это контрастирует с 1.3.x и более ранние выпуски, где class должен был быть задокументированный class

Наследуйтесь от классов и интерфейсов - Наследование комментариев происходит во всех трех возможных случаях наследования от классов и интерфейсов:

• Когда метод в class переопределяет метод в суперклассе
• Когда метод в интерфейсе переопределяет метод в суперинтерфейсе
• Когда метод в class реализует метод в интерфейсе

В первых двух случаях, для переопределений метода, инструмент Javadoc генерирует подзаголовок "Переопределения" в документации для метода переопределения со ссылкой к методу, который это переопределяет, наследован ли комментарий.

В третьем случае, когда метод в данном class реализует метод в интерфейсе, инструмент Javadoc генерирует подзаголовок, "Определенный" в документации для метода переопределения со ссылкой к методу, который это реализует. Это происходит, наследован ли комментарий.

Алгоритм для Наследования Комментариев Метода - Если метод не имеет комментария документа, или имеет {@inheritDoc} тег, инструмент Javadoc, ищет применимый комментарий, используя следующий алгоритм, который разрабатывается, чтобы найти самый определенный применимый комментарий документа, давая предпочтение интерфейсам по суперклассам:

1. Смотрите в каждом непосредственно реализованном (или расширенный) интерфейс в порядке, они появляются после реализаций слова (или расширяется) в объявлении метода. Используйте первый комментарий документа, найденный для этого метода.
2. Если шаг 1, отказавший, чтобы найти комментарий документа, рекурсивно примените этот весь алгоритм к каждому непосредственно реализованному (или расширенный) интерфейс в том же самом порядке, они были исследованы в шаге 1.
3. Если шаг 2, отказавший, чтобы найти комментарий документа и это - class кроме Объекта (не интерфейс):
4. 1. Если у суперкласса есть комментарий документа для этого метода, используйте это.
   2. Если шаг 3a, отказавший, чтобы найти комментарий документа, рекурсивно примените этот весь алгоритм к суперклассу.

ТЕГИ JAVADOC

Теги прибывают в два типа:

• Метки блока - Могут быть помещены только в разделе тега, который следует за основным описанием. Метки блока имеют форму: @tag.
• Встроенные теги - Могут быть помещены куда угодно в основном описании или в комментариях для меток блока. Встроенные теги обозначаются изогнутыми фигурными скобками: {@tag}.

Текущие теги:

Для пользовательских тегов см. - опция тега.

@author name-text

Добавляет запись "Автора" с указанным name-text к сгенерированным документам, когда - опция автора используется. Комментарий документа может содержать многократный @author теги. Можно определить одно имя на @author тег или многократные имена на тег. В прежнем случае инструмент Javadoc вставляет запятую (,) и пространство между именами. В последнем случае весь текст просто копируется в сгенерированный документ без того, чтобы быть проанализированным. Поэтому, можно использовать многократные имена на строку, если Вы хотите локализованный разделитель имени кроме запятой.

Для получения дополнительной информации см., Где Теги Могут Использоваться и пишущий @author теги.

@deprecated deprecated-text

Отметьте: Запускаясь с JDK 5.0, можно осудить элемент программы, используя @Deprecated аннотацию. Добавляет комментарий, указывающий, что этот API больше не должен использоваться (даже при том, что это может продолжать работать). Инструмент Javadoc перемещает deprecated-text перед основным описанием, помещая это курсивом и предшествуя этому с полужирным предупреждением: "Осуждаемый". Этот тег допустим во всех комментариях документа: краткий обзор, пакет, class, интерфейс, конструктор, метод и поле.

Первое предложение deprecated-text должно, по крайней мере, сказать пользователю, когда API осуждался и что использовать в качестве замены. Инструмент Javadoc копирует только первое предложение в сводный раздел, и индексировать. Последующие предложения могут также объяснить, почему это было осуждено. Следует включать a {@link} тег (для Javadoc 1.2 или позже), который указывает на заменяющий API:

Для получения дополнительной информации см. запись @deprecated теги.

• Для Javadoc 1.2 и позже, используйте a {@link} тег. Это создает встроенную ссылку, где Вы хотите ее. Например:

  /**
   * @deprecated  As of JDK 1.1, replaced by {@link #setBounds(int,int,int,int)}
   */
  

• Для Javadoc 1.1, стандартный формат должен создать a @see тег (который не может быть встроен) для каждого @deprecated тег.

Для больше об осуждении, см. тег @deprecated.

{@code text}

Эквивалентный <code>{@literal}</code>.

Дисплеи text в code шрифт, не интерпретируя текст как разметка HTML или вложенные теги javadoc. Это позволяет Вам использовать регулярные угловые скобки (< и >) вместо объектов HTML (< и >) в комментариях документа, такой как в типах параметра (<Object>), неравенства (3 < 4), или стрелки (<-). Например, текст комментария документа:

     {@code A<B>C}

дисплеи в сгенерированной неизменной странице HTML, как:

     A<B>C

Примечательная точка то, что <B> не интерпретируется как полужирный и находится в шрифте кода.

Если Вы хотите ту же самую функциональность без шрифта кода, использовать {@literal}.

{@docRoot}

Представляет относительный путь сгенерированному документу (место назначения) корневой каталог от любой сгенерированной страницы. Полезно, когда Вы хотите включать файл, такой как страница авторского права или логотип компании, на который Вы хотите сослаться от всех сгенерированных страниц. Соединение со страницей авторского права от нижней части каждой страницы распространено.

Это {@docRoot} тег может использоваться и на командной строке и в комментарии документа: Этот тег допустим во всех комментариях документа: краткий обзор, пакет, class, интерфейс, конструктор, метод и поле, включая текстовую часть любого тега (такого как @return, @param и @deprecated).

1. На командной строке, где заголовок/нижний колонтитул/нижняя часть определяются:

      javadoc -bottom '<a href="{@docRoot}/copyright.html">Copyright</a>'
   

   ОТМЕТЬТЕ - При использовании {@docRoot} этот путь в make-файле, некоторые программы make-файла требуют специального выхода для фигурной скобки {} символы. Например, Inprise ДЕЛАЮТ версию 5.2, работающую на Windows, требует двойных фигурных скобок: {{@docRoot}}. Это также требует двойной (а не единственный) кавычки включать параметры опциям такой как -bottom (с кавычками вокруг href опущенный параметр).
2. В комментарии документа:

      /**
       * See the <a href="{@docRoot}/copyright.html">Copyright</a>.
       */
   

Причина этот тег необходим, состоит в том, потому что сгенерированные документы находятся в иерархических каталогах, столь же глубоко как число подпакетов. Это выражение:

  <a href="{@docRoot}/copyright.html">

решил бы к:

  <a href="../../copyright.html">      for java/lang/Object.java

и

  <a href="../../../copyright.html">   for java/lang/ref/Reference.java

@exception class-name description

@exception тег является синонимом для @throws.

{@inheritDoc} 

Наследовался (копирует) документацию с "самого близкого" наследуемого class или интерфейса implementable в текущий комментарий документа в расположении этого тега. Это позволяет Вам писать более общим комментариям выше дерево наследования, и писать вокруг скопированного текста.

Этот тег допустим только в этих местах в комментарии документа:

• В основном блоке описания метода. В этом случае основное описание копируется с class или интерфейса иерархия.
• В текстовых параметрах @return, @param и @throws теги метода. В этом случае текст тега копируется с соответствующего тега иерархия.

См. Автоматическое Копирование Комментариев Метода для более точного описания того, как комментарии находятся в иерархии наследования. Отметьте, что, если этот тег отсутствует, комментарий или автоматически не наследован согласно правилам, описанным в том разделе.

{@link package.class#member label}

Вставляет встроенную ссылку с видимой текстовой меткой, которая указывает на документацию для указанного пакета, class или имени элемента class, на который ссылаются. Этот тег допустим во всех комментариях документа: краткий обзор, пакет, class, интерфейс, конструктор, метод и поле, включая текстовую часть любого тега (такого как @return, @param и @deprecated).

Этот тег очень simliar к @see – и потребуйте тех же самых ссылок и примите точно тот же самый синтаксис для package.class#member и label. Основное различие - это {@link} генерирует встроенную ссылку вместо того, чтобы поместить ссылку в, "См. Также" раздел. Кроме того, {@link} тег начинается и заканчивается изогнутыми фигурными скобками, чтобы разделить это от остальной части встроенного текста. Если Вы должны использовать"}" в метке, используйте нотацию объекта HTML }

Нет никакого предела числу {@link} теги позволяются в предложении. Можно использовать этот тег в основной части описания любого комментария для документации или в текстовой части любого тега (такого как @deprecated, @return или @param).

Например, вот комментарий, который относится к getComponentAt(int, int) метод:

Use the {@link #getComponentAt(int, int) getComponentAt} method.

От этого стандарт doclet генерировал бы следующий HTML (предполагающий, что это обращается к другому class в том же самом пакете):

Use the <a href="Component.html#getComponentAt(int, int)">getComponentAt</a> method.

Который появляется на веб-странице как:

Use the getComponentAt method.

Можно расшириться {@link} соединяться с классами, не задокументированными при использовании -link опция.

Для получения дополнительной информации см. запись {@link} теги.

{@linkplain package.class#member label}

Идентичный {@link}, кроме метки ссылки выводится на экран в простом тексте чем шрифт кода. Полезный, когда метка является простым текстом. Пример:

     Refer to {@linkplain add() the overridden method}.

Это вывело бы на экран как:

          Refer to the overridden method.

{@literal text}

Дисплеи text, не интерпретируя текст как разметка HTML или вложенные теги javadoc. Это позволяет Вам использовать регулярные угловые скобки (< и >) вместо объектов HTML (< и >) в комментариях документа, такой как в типах параметра (<Object>), неравенства (3 < 4), или стрелки (<-). Например, текст комментария документа:

     {@literal A<B>C}

дисплеи, неизменные в сгенерированной странице HTML в Вашем браузере, как:

     <B> C

Примечательная точка то, что <B> не интерпретируется как полужирный (и это не находится в шрифте кода).

Если Вы хотите ту же самую функциональность, но с текстом в шрифте кода, использовать {@code}.

@param parameter-name description

Добавляет параметр с указанным parameter-name, сопровождаемым указанным description к разделу "Параметров". При записи комментария документа можно продолжать description на многократные строки. Этот тег допустим только в комментарии документа для метода, конструктора или class.

parameter-name может быть именем параметра в методе или конструкторе, или именем параметра типа class, метода или конструктора. Используйте угловые скобки вокруг этого названия параметра, чтобы определить использование параметра типа.

Пример параметра типа class:

     /**
      * @param <E> Type of element stored in a list
      */
     public interface List<E> extends Collection<E> {
     }

Пример параметра типа метода:

     /**
      * @param string  the string to be converted
      * @param type    the type to convert the string to
      * @param <T>     the type of the element
      * @param <V>     the value of the element
      */
     <T, V extends T> V convert(String string, Class<T> type) {
     }

Для получения дополнительной информации см. запись @param теги.

@return description

Добавляет раздел "Возвратов" с текстом description. Этот текст должен описать тип возврата и допустимый диапазон значений. Этот тег допустим только в комментарии документа для метода.

Для получения дополнительной информации см. запись @return теги.

@see reference

Добавляет, "Видят Также" заголовок со ссылкой или вводом текста, который указывает на reference. Комментарий документа может содержать любое число @see теги, которые все группируются в соответствии с тем же самым заголовком. @see у тега есть три изменения; третья форма ниже наиболее распространена. Этот тег допустим в любом комментарии документа: краткий обзор, пакет, class, интерфейс, конструктор, метод или поле. Для того, чтобы вставить встроенную ссылку в пределах предложения к пакету, class или элементу, см. {@link}.

@see "string"

Добавляет ввод текста для string. Никакая ссылка не сгенерирована. string является книгой или другой ссылкой на информацию, не доступную URL. Инструмент Javadoc отличает это от предыдущих случаев, ища двойную кавычку (") как первый символ. Например:

@see "The Java Programming Language"

Это генерирует текст, такой как:

See Also:
     "The Java Programming Language"

@see <a href="URL#value">label</a>

Добавляет ссылку как определено URL#value. URL#value является относительный или абсолютный URL. Инструмент Javadoc отличает это от других случаев, ища меньше символ (<) как первый символ. Например:

@see <a href="spec.html#section">Java Spec</a>

Это генерирует ссылку, такую как:

See Also:
      Java Spec

@see package.class#member label

Добавляет ссылку, с видимым текстом label, который указывает на документацию для указанного имени на Языке Java, на который ссылаются. label является дополнительным; если опущено, имя появляется вместо этого, как видимый текст, соответственно сокращенный – видит, Как имя выводится на экран. Используйте-noqualifier, чтобы глобально удалить имя пакета из этого видимого текста. Используйте метку, когда Вы хотите, чтобы видимый текст отличался от автоматически сгенерированного видимого текста.

Только в версии 1.2, только имя, но не метка автоматически появилось бы в <коде>, HTML-тэги, Запускающиеся с 1.2.2, <код>, всегда включаются вокруг видимого текста, используется ли метка.

• package.class#member является любым допустимым именем элемента программы, на которое ссылаются – пакет, class, интерфейс, конструктор, имя метода или имя поля – за исключением того, что символ перед именем элемента должен быть символом хеша (#). class представляет любой верхний уровень или вкладывал class или интерфейс. member представляет любого конструктора, метод или поле (не вложенный class или интерфейс). Если это имя будет в задокументированных классах, то инструмент Javadoc автоматически создаст ссылку к нему. Чтобы создать ссылки к внешним классам, на которые ссылаются, используйте -link опция. Используйте любой из других двух @see формы для того, чтобы сослаться на документацию имени, которое не принадлежит class, на который ссылаются. Этот параметр описывается в большей длине ниже при Определении Имени.
• label является дополнительным текстом, который видим как метка ссылки. label может содержать пробел. Если label опускается, то пакет. class.member появится, соответственно сокращенный относительно текущего class и пакета – видят, Как имя выводится на экран.
• Пространство является разделителем между package.class#member и label. Пространство в круглых скобках не указывает на запуск метки, таким образом, пробелы могут использоваться между параметрами в методе.

Пример - В этом примере, @see тег (в Character class), обращается к equals метод в String class. Тег включает оба параметра: имя"String#equals(Object)"и метка"equals".

 /**
  * @see String#equals(Object) equals
  */

Стандарт doclet производит HTML что-то вроде этого:

<dl>
<dt><b>See Also:</b>
<dd><a href="../../java/lang/String#equals(java.lang.Object)"><code>equals<code></a>
</dl>

Который выглядит примерно так в браузере, где метка является видимым текстом ссылки:

See Also:
      equals

Определение имени - Этот package.class#Имя member может быть или полностью определено, такой как java.lang.String#toUpperCase() или нет, такой как String#toUpperCase() или #toUpperCase(). Если менее чем полностью определенный, инструмент Javadoc использует нормальный порядок поиска компилятора Java счесть это, далее описанным ниже в порядке Поиска на @see. Имя может содержать пробел в пределах круглых скобок, такой как между параметрами метода.

Конечно, преимущество обеспечения более коротких, "частично квалифицированных" имен состоит в том, что они короче, чтобы ввести и в исходном коде есть меньше помехи. Следующая таблица показывает различные формы имени, где Class может быть class или интерфейс, Type может быть class, интерфейс, массив, или примитивный, и method могут быть методом или конструктором.

Типичные формы для @see package.class#member

Ссылка на элемент текущего class @see #field @see #method(Type, Type,...) @see #method(Type argname, Type argname,...) @see #constructor(Type, Type,...) @see #constructor(Type argname, Type argname,...) Ссылка на другой class в текущих или импортированных пакетах @see Class#field @see Class#method(Type, Type,...) @see Class#method(Type argname, Type argname,...) @see Class#constructor(Type, Type,...) @see Class#constructor(Type argname, Type argname,...) @see Class.NestedClass @see Class Ссылка на элемент в другом пакете (полностью определяется) @see package.Class#field @see package.Class#method(Type, Type,...) @see package.Class#method(Type argname, Type argname,...) @see package.Class#constructor(Type, Type,...) @see package.Class#constructor(Type argname, Type argname,...) @see package.Class.NestedClass @see package.Class @see package

Следующие примечания применяются к вышеупомянутой таблице:

• Первый набор форм (без class или пакета) заставит инструмент Javadoc искать только через иерархию текущего class. Это найдет элемент текущего class или интерфейса, одного из его суперклассов или суперинтерфейсов, или одного из его классов включения или интерфейсов (шаги 1-3 поиска). Это не будет искать остальную часть текущего пакета или других пакетов (шаги 4-5 поиска).
• Если какой-либо метод или конструктор вводятся как имя без круглых скобок, такой как getValue, и если не будет никакого поля с тем же самым именем, то инструмент Javadoc правильно создаст ссылку к нему, но напечатает предупреждающее сообщение, напоминающее Вам добавить круглые скобки и параметры. Если этот метод будет перегружен, то инструмент Javadoc соединится с первым методом, с которым встречается его поиск, который является неуказанным.
• Вложенные классы должны быть определены как outer.inner, не просто inner, для всех форм.
• Как утверждено, символ хеша (#), а не точка (.) разделяет элемент от его class. Это позволяет инструменту Javadoc разрешить неоднозначности, так как точка также разделяет классы, вложенные классы, пакеты, и подпакеты. Однако, инструмент Javadoc обычно снисходителен и должным образом проанализирует точку, если Вы знаете, что нет никакой неоднозначности, хотя он напечатает предупреждение.

Порядок поиска на @see - инструмент Javadoc обработает a @see тег, который появляется в исходном файле (.java), файл пакета (package.html или пакет-info.java) или файл краткого обзора (overview.html). В последних двух файлах следует полностью определить имя, которое Вы предоставляете @see. В исходном файле можно определить имя, которое полностью определяется или частично квалифицируется.

Когда инструмент Javadoc встречается с a @see тег в a .java файл, который не полностью определяется, это ищет указанное имя в том же самом порядке, как компилятор Java был бы (кроме инструмента Javadoc, не будет обнаруживать определенные неоднозначности пространства имен, так как это предполагает, что исходный код свободен от этих ошибок). Этот порядок поиска формально определяется в Спецификации языка Java. Поиски инструмента Javadoc того имени через все связанные и импортированные классы и пакеты. В частности это ищет в этом порядке:

1. текущий class или интерфейс
2. любые классы включения и интерфейсы, ища самый близкий сначала
3. любые суперклассы и суперинтерфейсы, ища самый близкий сначала
4. текущий пакет
5. любые импортированные пакеты, классы и интерфейсы, ищущие в порядке оператора импорта

Инструмент Javadoc продолжает искать рекурсивно через шаги 1-3 для каждого class, с которым он встречается, пока он не находит соответствие. Таким образом, после того, как это перероет текущий class и его включение class E, это перероет суперклассы Э перед классами включения Э. В шагах 4 и 5 инструмент Javadoc не ищет классы или интерфейсы в пределах пакета в любом указанном порядке (что порядок зависит от определенного компилятора). В шаге 5, видах инструмента Javadoc в java.lang, так как это автоматически импортируется всеми программами.

Инструмент Javadoc не обязательно смотрит в подклассах, и при этом это не будет смотреть в других пакетах, даже если их документация будет сгенерирована в том же самом выполнении. Например, если @see тег находится в java.awt.event.KeyEvent class и обращается к имени в java.awt пакет, javadoc не смотрит в том пакете если, что class импортирует это.

Как имя выводится на экран - Если label опускается, то пакет. class.member появляется. Вообще, это соответственно сокращается относительно текущего class и пакета. "Сокращенным" мы подразумеваем, что инструмент Javadoc выводит на экран только минимальное необходимое имя. Например, если String.toUpperCase() метод содержит ссылки на элемент того же самого class и к элементу различного class, имя class выводится на экран только в последнем случае, как показано в следующей таблице.

Используйте-noqualifier, чтобы глобально удалить имена пакета.

Тип Ссылки	Пример в String.toUpperCase()	Дисплеи Как
@see тег обращается к элементу того же самого class, того же самого пакета	@see String#toLowerCase()	toLowerCase() (опускает пакет и имена class),
@see тег обращается к элементу различного class, того же самого пакета	@see Character#toLowerCase(char)	Character.toLowerCase(char) (опускает имя пакета, включает имя class),
@see тег обращается к элементу различного class, различного пакета	@see java.io.File#exists()	java.io.File.exists() (включает пакет и имена class),

Примеры @see
Комментарий к праву показывает, как имя было бы выведено на экран если @see тег находится в class в другом пакете, такой как java.applet.Applet.

                                           See also:
@see java.lang.String                   //  String                          
@see java.lang.String The String class  //  The String class                
@see String                             //  String                          
@see String#equals(Object)              //  String.equals(Object)           
@see String#equals                      //  String.equals(java.lang.Object) 
@see java.lang.Object#wait(long)        //  java.lang.Object.wait(long)     
@see Character#MAX_RADIX                //  Character.MAX_RADIX             
@see <a href="spec.html">Java Spec</a>  //  Java Spec           
@see "The Java Programming Language"    //  "The Java Programming Language"        

Можно расшириться @see соединяться с классами, не задокументированными при использовании -link опция.

Для получения дополнительной информации см. запись @see теги.

@serial field-description | include | exclude

Используемый в документе комментируют для значения по умолчанию сериализуемое поле.

Дополнительный field-description должен объяснить значение поля и перечислить приемлемые значения. Если нужно описание может охватить многократные строки. Стандарт doclet добавляет эту информацию к сериализированной странице формы.

Если бы сериализуемое поле было добавлено к class некоторое время после того, как class был сделан сериализуемым, то оператор должен быть добавлен к его основному описанию, чтобы идентифицировать, в которой версии это было добавлено.

include и exclude параметры идентифицируют, должны ли class или пакет быть включены или исключены из сериализированной страницы формы. Они работают следующим образом:

• Общедоступный или защищенный class, который реализует Serializable не включается если, что class (или его пакет) отмечается @serial exclude.
• Частный или частный на пакет class, который реализует Serializable не исключается если, что class (или его пакет) отмечается @serial include.

Примеры: javax.swing пакет отмечается @serial exclude (в package.html или package-info.java). Общедоступный class java.security.BasicPermission отмечается @serial exclude. Частный на пакет class java.util.PropertyPermissionCollection отмечается @serial include.

Тег @serial на уровне class переопределяет @serial на уровне пакета.

Для получения дополнительной информации о том, как использовать эти теги, наряду с примером, см. "Документирующие Сериализуемые Поля и Данные для Класса," Раздел 1.6 из Спецификации Сериализации Объекта Java. Также см. FAQ Сериализации, который покрывает общие вопросы, такой как, "Почему я вижу javadoc предупреждения утвердить, что я пропускаю теги @serial для частных полей, если я не выполняю javadoc с - частный переключатель?". Также см. критерии Sun для включения классов в сериализированной спецификации формы.

@serialField field-name field-type field-description

Документирует ObjectStreamField компонент a Serializable class serialPersistentFields элемент. Один @serialField тег должен использоваться для каждого ObjectStreamField компонент.

@serialData data-description

data-description документирует типы и порядок данных в сериализированной форме. Определенно, эти данные включают дополнительные данные, записанные writeObject метод и все данные (включая базовые классы) записанный Externalizable.writeExternal метод.

@serialData тег может использоваться в комментарии документа для writeObject, readObject, writeExternal, readExternal, writeReplace, и readResolve методы.

@since since-text

Добавляет "Начиная с" заголовка с указанным since-text к сгенерированной документации. У текста нет никакой специальной внутренней структуры. Этот тег допустим в любом комментарии документа: краткий обзор, пакет, class, интерфейс, конструктор, метод или поле. Этот тег означает, что это изменение или функция существовали начиная с выпуска программного обеспечения, определенного since-text. Например:

    @since 1.5

Для исходного кода в платформе Java этот тег указывает на версию спецификации API платформы Java (не обязательно, когда это было добавлено к ссылочной реализации). Многократные теги @since позволяются и обрабатываются как многократные теги @author. Вы могли использовать многократные теги, если prgram элемент используется больше чем одним API.

@throws class-name description

@throws и @exception теги являются синонимами. Добавляет подзаголовок "Бросков" к сгенерированной документации с текстом description и class-name. class-name является именем исключения, которое может быть выдано методом. Этот тег допустим только в комментарии документа для метода или конструктора. Если этот class не является полностью указанным, инструмент Javadoc использует порядок поиска искать этот class. Многократный @throws теги могут использоваться в данном комментарии документа для тех же самых или различных исключений.

Гарантировать, что все проверенные исключения документируются, если a @throws тег не существует для исключения в пункте бросков, инструмент Javadoc автоматически добавляет, что исключение к выводу HTML (без описания), как будто это было задокументировано с тегом @throws.

@throws документация копируется от переопределенного метода до подкласса только, когда исключение явно объявляется в переопределенном методе. То же самое является истиной для того, чтобы скопировать от метода интерфейса до метода реализации. Можно использовать {@inheritDoc}, чтобы вынудить @throws наследовать документацию.

Для получения дополнительной информации см. запись @throws теги.

{@value package.class#field}

Когда {@value} используется (без любого параметра) в комментарии документа статического поля, это выводит на экран значение той константы:

    /**
     * The value of this constant is {@value}.
     */
    public static final String SCRIPT_START = "<script>"

Когда использующийся с параметром package.class#field в любом комментарии документа, это выводит на экран значение указанной константы:

    /**
     * Evaluates the script starting with {@value #SCRIPT_START}.
     */
    public String evalScript(String script) {
    }

package.class#field параметра принимает форму, идентичную тому из @see параметра, за исключением того, что элемент должен быть статическим полем.

Эти значения этих констант также выводятся на экран на Постоянной странице Значений полей.

@version version-text

Добавляет подзаголовок "Версии" с указанным version-text к сгенерированным документам, когда - опция версии используется. Этот тег предназначается, чтобы содержать число текущей версии программного обеспечения, из которого этот код является частью (в противоположность @since, который содержит номер версии, где этот код был представлен). У version-text нет никакой специальной внутренней структуры. Чтобы видеть, где тег версии может использоваться, см., Где Теги Могут Использоваться.

Комментарий документа может содержать многократный @version теги. Если это имеет смысл, можно определить один номер версии на @version тег или многократные номера версий на тег. В прежнем случае инструмент Javadoc вставляет запятую (,) и пространство между именами. В последнем случае весь текст просто копируется в сгенерированный документ без того, чтобы быть проанализированным. Поэтому, можно использовать многократные имена на строку, если Вы хотите локализованный разделитель имени кроме запятой.

Для получения дополнительной информации см. запись @version теги.

Где Теги Могут Использоваться

Теги Документации краткого обзора

ОТМЕТЬТЕ - {@link} у тега есть ошибка в документах краткого обзора в версии 1.2 – текст появляется должным образом, но не имеет никакой ссылки. {@docRoot} тег в настоящий момент не работает в документах краткого обзора.

Теги Документации пакета

Класс и Теги Документации Интерфейса

Пример комментария class:

/**
 * A class representing a window on the screen.
 * For example:
 * <pre>
 *    Window win = new Window(parent);
 *    win.show();
 * </pre>
 *
 * @author  Sami Shaio
 * @version 1.15, 13 Dec 2006
 * @see     java.awt.BaseWindow
 * @see     java.awt.Button
 */
class Window extends BaseWindow {
   ...
}

Полевые Теги Документации

Пример полевого комментария:

    /**
     * The X-coordinate of the component.
     *
     * @see #getLocation()
     */
    int x = 1263732;

Конструктор и Теги Документации Метода

Пример комментария документа метода:

    /**
     * Returns the character at the specified index. An index
     * ranges from <code>0</code> to <code>length() - 1</code>.
     *
     * @param     index  the index of the desired character.
     * @return    the desired character.
     * @exception StringIndexOutOfRangeException
     *              if the index is not in the range <code>0</code>
     *              to <code>length()-1</code>.
     * @see       java.lang.Character#charValue()
     */
    public char charAt(int index) {
       ...
    }

ОПЦИИ

Опции:

Опции Javadoc

- краткий обзор  path\filename

Определяет, что javadoc должен получить текст для документации краткого обзора от "исходного" файла, определенного путем/именем файла, и поместить это на странице Краткого обзора (overview-summary.html). Путь/имя файла относительно текущего каталога.

В то время как можно использовать любое имя, Вы хотите для имени файла и помещаете его куда угодно, Вы хотите для пути, типичная вещь сделать состоит в том, чтобы назвать его overview.html и поместите это в исходное дерево в каталоге, который содержит самые верхние каталоги пакета. В этом расположении никакой путь не необходим, документируя пакеты с тех пор -sourcepath укажет на этот файл. Например, если исходное дерево для java.lang пакет C:\src\classes\java\lang\, тогда Вы могли поместить файл краткого обзора в C:\src\classes\overview.html. См. Пример Реального мира.

Для получения информации о файле, определенном путем/именем файла, см. файл комментария краткого обзора.

Отметьте, что страница краткого обзора создается, только если Вы передаете в javadoc два или больше имени пакета. Для дальнейшего объяснения см. Фреймы HTML.)

title на странице краткого обзора устанавливается -doctitle.

- общественность

Шоу только общедоступные классы и элементы.

- защищенный

Шоу только защищенные и общедоступные классы и элементы. Это - значение по умолчанию.

- пакет

Шоу только пакет, защищенные, и общедоступные классы и элементы.

- частный

Шоу все классы и элементы.

- справка

Выводит на экран онлайновую справку, которая перечисляет эти javadoc и doclet параметры командной строки.

-doclet class

Определяет файл class, который запускает doclet, используемый в генерировании документации. Используйте полностью определенное имя. Этот doclet определяет контент и форматирует вывод. Если -doclet опция не используется, javadoc использует стандарт doclet для того, чтобы генерировать формат HTML значения по умолчанию. Этот class должен содержать start(Root) метод. Путь к этому запуску class определяется -docletpath опция.

Например, чтобы вызвать MIF doclet, используйте:

    -doclet com.sun.tools.doclets.mif.MIFDoclet

Для полных, рабочих примеров выполнения определенного doclet см. MIF Doclet документация.

-docletpath classpathlist

Определяет путь к doclet запускающийся файл class (определенный с -doclet опция), и любые файлы фляги это зависит от. Если запускающийся файл class находится в файле фляги, то это определяет путь к тому файлу фляги, как показано в примере ниже. Можно определить абсолютный путь или путь относительно текущего каталога. Если classpathlist содержит разнообразные пути или файлы фляги, они должны быть разделены двоеточием (:) на Солярисе и точке с запятой (;) на Windows. Эта опция не необходима, если doclet запускающийся class уже находится в пути поиска.

Пример пути к файлу фляги, который содержит запуск doclet файл class. Заметьте, что имя файла фляги включается.

-docletpath C:\user\mifdoclet\lib\mifdoclet.jar

Пример пути к запуску doclet файл class. Заметьте, что имя файла class опускается.

-docletpath C:\user\mifdoclet\classes\com\sun\tools\doclets\mif\

Для полных, рабочих примеров выполнения определенного doclet см. MIF Doclet документация.

-1.1

Эта функция была удалена из Javadoc 1.4. Нет никакой замены для этого. Эта опция создаваемая документация с появлением и функциональностью документации, сгенерированной Javadoc 1.1 (это никогда не поддерживало вложенные классы). Если Вы нуждаетесь в этой опции, используйте Javadoc 1.2 или 1.3 вместо этого.

- исходный выпуск

Определяет версию принятого исходного кода. Следующие значения для выпуска позволяются:

Значение выпуска	Примечания
1.5	javadoc принимает код, содержащий обобщения и другие функции языка, представленные в JDK 1.5. Значения по умолчанию компилятора к 1.5 поведениям, если - исходный флаг не используется.
1.4	javadoc принимает код, содержащий утверждения, которые были представлены в JDK 1.4.
1.3	javadoc не поддерживает утверждения, обобщения, или другие функции языка, представленные после JDK 1.3.

Используйте значение выпуска, соответствующего используемому, компилируя код с javac.

-sourcepath sourcepathlist

Определяет пути поиска для того, чтобы найти исходные файлы (.java) передавая имена пакета или -subpackages в javadoc команда. sourcepathlist может содержать разнообразные пути, разделяя их точкой с запятой (;). Инструмент Javadoc будет искать во всех подкаталогах указанных путей. Отметьте, что эта опция не только используется, чтобы определить местоположение исходных файлов, задокументированных, но также и найти исходные файлы, которые не документируются, но чьи комментарии наследованы задокументированными исходными файлами.

Отметьте, что можно использовать -sourcepath опция только, передавая пакет называет в javadoc команду – это не будет располагаться .java файлы, которые передают в javadoc команда. (Чтобы расположиться .java файлы, cd к тому каталогу или включают путь перед каждым файлом, как показано при Документировании Того или Большего количества Классов.), Если -sourcepath опускается, javadoc использует путь class, чтобы найти исходные файлы (см. - путь к классу). Поэтому, значение по умолчанию-sourcepath является значением пути class. Если - путь к классу опускается, и Вы передаете имена пакета в javadoc, это смотрит в текущем каталоге (и подкаталоги) для исходных файлов.

Установите sourcepathlist в корневой каталог исходного дерева для пакета, который Вы документируете. Например, предположите, что Вы хотите задокументировать вызванный пакет com.mypackage чьи исходные файлы располагаются в:

C:\user\src\com\mypackage\*.java

В этом случае Вы определили бы sourcepath к C:\user\src, каталог, который содержит com\mypackage, и затем предоставьте имя пакета com.mypackage:

  C:> javadoc -sourcepath C:\user\src com.mypackage

Это легко помнить, замечая, что, если Вы связываете значение sourcepath и имени пакета вместе и изменяете точку на наклонную черту влево "\", Вы заканчиваете с полным путем к пакету: C:\user\src\com\mypackage.

Указать на два исходных пути:

  C:> javadoc -sourcepath C:\user1\src;C:\user2\src com.mypackage

- путь к классу classpathlist

Определяет пути, где javadoc будет искать классы, на которые ссылаются (.class файлы) – они - задокументированные классы плюс любые классы, на которые ссылаются те классы. classpathlist может содержать разнообразные пути, разделяя их точкой с запятой (;). Инструмент Javadoc будет искать во всех подкаталогах указанных путей. Следуйте инструкциям в документации пути class для того, чтобы определить classpathlist.

Если -sourcepath опускается, использование инструмента Javadoc -classpath найти исходные файлы так же как файлы class (для обратной совместимости). Поэтому, если Вы хотите искать источник и файлы class в отдельных путях, используйте обоих -sourcepath и -classpath.

Например, если Вы хотите задокументировать com.mypackage, чьи исходные файлы находятся в каталоге C:\user\src\com\mypackage, и если этот пакет полагается на библиотеку в C:\user\lib, Вы определили бы:

  C:> javadoc -classpath \user\lib -sourcepath \user\src com.mypackage

Как с другими инструментами, если Вы не определяете -classpath, инструмент Javadoc использует переменную окружения ПУТИ К КЛАССУ, если это устанавливается. Если оба не устанавливаются, инструмент Javadoc ищет классы из текущего каталога.

Для всестороннего описания того, как инструмент Javadoc использует -classpath чтобы найти пользовательские классы, поскольку это касается классов расширения и классов начальной загрузки, см., Как Классы Находятся.

Как специальное удобство, элемент пути class, содержащий базовое имя * считается эквивалентным определению списка всех файлов в каталоге с расширением .jar или .JAR (программа java не может сказать различие между этими двумя вызовами).

Например, если каталог foo содержит a.jar и b.JAR, тогда элемент пути class foo/* расширяется до a A.jar:b.JAR, за исключением того, что порядок файлов фляги является неуказанным. Все файлы фляги в указанном каталоге, даже скрытых, включаются в список. Запись пути к классу, состоящая просто из * расширяется до списка всех файлов фляги в текущем каталоге. CLASSPATH переменная окружения, где определено, будет так же расширена. Любое подстановочное расширение пути к классу происходит прежде, чем виртуальная машина Java запускается – никакая программа Java никогда не будет видеть нерасширенные подстановочные знаки кроме, запрашивая среду. Например; вызывая System.getenv("CLASSPATH").

-subpackages  package1:package2:...

Генерирует документацию от исходных файлов в указанных пакетах и рекурсивно в их подпакетах. Эта опция полезна, добавляя новые подпакеты к исходному коду, поскольку они автоматически включаются. Каждым параметром пакета является любой высокоуровневый подпакет (такой как java) или полностью определенный пакет (такой как javax.swing) это не должно содержать исходные файлы. Параметры разделяются двоеточиями (на всей работе systmes). Подстановочные знаки не необходимы или позволяются. Использовать -sourcepath определить, где найти пакеты. Эта опция умна о не обработке исходных файлов, которые находятся в исходном дереве, но не принадлежат пакетам, как описано при обработке исходных файлов.

Например:

  C:> javadoc -d docs -sourcepath C:\user\src -subpackages java:javax.swing

Эта команда генерирует документацию для пакетов, названных "java" и "javax.swing" и всеми их подпакетами.

Можно использовать -subpackages в соединении с -exclude исключить определенные пакеты.

- исключают  packagename1:packagename2:...

Безоговорочно исключает указанные пакеты и их подпакеты от списка, сформированного -subpackages. Это исключает те пакеты, даже если они были бы иначе включены некоторыми предыдущими или позже -subpackages опция. Например:

  C:> javadoc -sourcepath C:\user\src -subpackages java -exclude java.net:java.lang

включал бы java.io, java.util, и java.math (среди других), но исключил бы пакеты, базированные в java.net и java.lang. Заметьте, что это исключает java.lang.ref, подпакет java.lang).

-bootclasspath classpathlist

Определяет пути, где классы начальной загрузки находятся. Они - номинально классы платформы Java. bootclasspath является частью пути поиска, который инструмент Javadoc будет использовать, чтобы искать файлы class и источник. См., Как Классы Находятся. для большего количества деталей. Отдельные каталоги в classpathlist с точками с запятой (;).

-extdirs dirlist

Определяет каталоги, где классы расширения находятся. Они - любые классы, которые используют механизм Расширения Java. extdirs является частью пути поиска, который инструмент Javadoc будет использовать, чтобы искать файлы class и источник. См. -classpath (выше) для большего количества деталей. Отдельные каталоги в dirlist с точками с запятой (;).

- многословный

Обеспечивает более подробные сообщения, в то время как javadoc работает. Без многословной опции сообщения появляются для того, чтобы загрузить исходные файлы, генерируя документацию (одно сообщение на исходный файл), и сортировка. Многословная опция заставляет печать дополнительных сообщений, определяющих число миллисекунд анализировать каждый исходный файл java.

- тихий

Отключает неошибку и непредупреждающие сообщения, оставляя только предупреждения, и ошибки кажутся, делая их легче просмотреть. Также подавляет строку версии.

-breakiterator 

Использует интернационализировавшую границу предложения java.text.BreakIterator определить конец первого предложения для английского языка (все другие локали уже используют BreakIterator), а не английский язык, специфичный для локали алгоритм. Первым предложением мы имеем в виду первое предложение в основном описании пакета, class или элемента. Это предложение копируется в пакет, class или задействованная сводка, и в алфавитное индексируют.

От JDK 1.2 прямой, BreakIterator class уже используется, чтобы определить конец предложения для всех языков, но английского языка. Поэтому, -breakiterator опция не имеет никакого эффекта за исключением английского языка от 1.2 вперед. У английского языка есть свой собственный алгоритм значения по умолчанию:

• Английский алгоритм повреждения предложения значения по умолчанию - Остановки в период, сопровождаемый пространством или меткой блока HTML, такой как <P>.
• Алгоритм повреждения предложения Breakiterator - Вообще, остановки в период, вопросительный знак или восклицательный знак, сопровождаемый пространством, если следующее слово запускается с прописной буквы. Это предназначается, чтобы обработать большинство сокращений (таких как "Сериал нет. допустимо", но не будет обрабатывать "г-на Смита"). Не останавливается в HTML-тэгах или предложениях, которые начинаются с чисел или символов. Остановки в прошлый период в ".."/имя файла, даже если встроенный в HTML-тэг.

ОТМЕТЬТЕ: Мы удалили breakiterator предупреждающие сообщения от 1.5.0, которые были в 1.4.x и оставили алгоритм повреждения предложения значения по умолчанию неизменным. Таким образом,-breakiterator опция не является значением по умолчанию в 1.5.0, и при этом мы не ожидаем, что это станет значением по умолчанию. Это - реверсирование от нашего прежнего намерения, что значение по умолчанию изменилось бы в "следующей главной версии" (1.5.0). Это означает, не изменили ли Вы свой исходный код, чтобы устранить breakiterator предупреждения в 1.4.x, тогда Вы ничего не должны сделать, и предупреждения уходят, запускаясь с 1.5.0. Причина этого реверсирования состоит в том, потому что любое преимущество к наличию breakiterator становится значением по умолчанию, был бы перевешен несовместимым исходным изменением, которого это потребует. Мы сожалеем о любой дополнительной работе и беспорядке, который это вызвало.

- локаль language_country_variant

Важный - -locale опция должна быть помещена вперед (налево) любых возможностей, предоставленных стандартом doclet или любым другим doclet. Иначе, панели навигации появятся на английском языке. Это - единственный параметр командной строки, который зависим от порядка.

Определяет локаль, которую javadoc использует, генерируя документацию. Параметром является имя локали, как описано в java.util. Документация локали, такой как en_US (Английский язык, Соединенные Штаты) или en_US_WIN (Разновидность Windows).

Определение локали заставляет javadoc выбирать файлы ресурсов той локали для сообщений (строки в панели навигации, заголовках для списков и таблиц, содержания справочного файла, комментариев в stylesheet.css, и т.д). Это также определяет порядок сортировки для списков, сортированных в алфавитном порядке, и разделитель предложения, чтобы определить конец первого предложения. Это не определяет локаль текста комментария документа, определенного в исходных файлах задокументированных классов.

- кодирующий имя

Определяет имя кодирования исходных файлов, такой как EUCJIS/SJIS. Если эта опция не определяется, преобразователь значения по умолчанию платформы используется.

Также см.-docencoding и - набор символов.

-Jflag

Передачи отмечают непосредственно к системному java времени выполнения, который выполняет javadoc. Уведомление там не должно быть никаким пространством между J и флаг. Например, если Вы должны гарантировать, что система откладывает 32 мегабайта памяти, в которой можно обработать сгенерированную документацию, тогда Вы вызвали бы -Xmx опция java следующим образом (-Xms является дополнительным, поскольку это только устанавливает размер начальной памяти, которая полезна, если Вы знаете минимальное количество требуемой памяти):

   C:> javadoc -J-Xmx32m -J-Xms32m com.mypackage

Чтобы сказать, какую версию javadoc Вы используете, вызовите"-version"опция java:

   C:> javadoc -J-version
   java version "1.2"
   Classic VM (build JDK-1.2-V, green threads, sunwjit)

(Номер версии стандарта doclet появляется в его потоке вывода.)

Возможности, предоставленные Стандартным Doclet

-d directory

Определяет целевой каталог, где javadoc сохранил сгенерированные файлы HTML. ("d" означает "место назначения."), Опускающий эту опцию заставляет файлы быть сохраненными к текущему каталогу. Значение directory может быть абсолютным, или относительно текущего рабочего каталога. С 1.4, автоматически создается целевой каталог, когда javadoc выполняется.

Например, следующее генерирует документацию для пакета com.mypackage и сохраняет результаты в C:\user\doc\ каталог:

  C:> javadoc -d \user\doc com.mypackage

- используют

Включает одну страницу "Использования" для каждого, задокументировал class и пакет. Страница описывает то, что упаковывает, классы, методы, конструкторы и поля используют любой API данного class или пакета. Данный class C, вещи, которые используют class C, включали бы подклассы C, поля, объявленные как C, методы, которые возвращают C, и методы и конструкторов с параметрами типа C.

Например, давайте смотреть на то, что могло бы появиться на странице "Использования" для Строки. getName() метод в java.awt.Font class возвращает тип String. Поэтому, getName() использование String, и Вы найдете что метод на странице "Использования" для String.

Отметьте, что это документирует только использование API, не реализацию. Если метод использует String в его реализации, но не берет строку в качестве параметра или возвращает строку, которую не считают "использованием" String.

Можно получить доступ к сгенерированной странице "Использования" первым движением к class или пакету, затем щелкая по ссылке "Использования" в панели навигации.

- версия

Включает @version текст в сгенерированные документы. Этот текст опускается по умолчанию. Чтобы сказать, какую версию инструмента Javadoc Вы используете, используйте -J-version опция.

- автор

Включает @author текст в сгенерированные документы.

-splitindex

Разделяет индексный файл на многократные файлы, в алфавитном порядке, один файл на букву, плюс файл для любых элементов индекса, которые запускаются с неалфавитных символов.

-windowtitle title

Определяет title, который будет помещен в HTML <title> тег. Это кажется в окне title и в любых закладках браузера (любимые места), что кто-то создает для этой страницы. Этот title не должен содержать HTML-тэги, поскольку браузер не будет должным образом интерпретировать их. Любые внутренние кавычки в пределах title, вероятно, придется оставить. Если-windowtitle опускается, инструмент Javadoc использует значение-doctitle для этой опции.

  C:> javadoc -windowtitle "Java SE Platform" com.mypackage

-doctitle title

Определяет title, который будет помещен около вершины сводного файла краткого обзора. title будет помещен как центрируемый, выровняет тот, возглавляющий непосредственно ниже верхней панели навигации. title может содержать html-тэги и пробел, хотя, если это делает, это должно быть включено в кавычки. Любые внутренние кавычки в пределах title, вероятно, придется оставить.

  C:> javadoc -doctitle "Java™" com.mypackage

-title title

Эта опция больше не существует. Это существовало только в Бета-версиях Javadoc 1.2. Это было переименовано к -doctitle. Эта опция переименовывается, чтобы прояснить, что она определяет документ title, а не окно title.

- заголовок заголовка

Определяет текст заголовка, который будет помещен наверху каждого выходного файла. Заголовок будет помещен направо от верхней панели навигации. заголовок может содержать HTML-тэги и пробел, хотя, если это делает, это должно быть включено в кавычки. Любые внутренние кавычки в пределах заголовка, вероятно, придется оставить.

  C:> javadoc -header "<b>Java 2 Platform </b><br>v1.4" com.mypackage

Футов длиной нижний колонтитул

Определяет текст нижнего колонтитула, который будет помещен у основания каждого выходного файла. Нижний колонтитул будет помещен направо от более низкой панели навигации. нижний колонтитул может содержать html-тэги и пробел, хотя, если это делает, это должно быть включено в кавычки. Любые внутренние кавычки в нижнем колонтитуле, вероятно, придется оставить.

- вершина

Определяет текст, который будет помещен наверху каждого выходного файла.

- нижний текст

Определяет текст, который будет помещен у основания каждого выходного файла. Текст будет помещен внизу страницы ниже более низкой панели навигации. text может содержать HTML-тэги и пробел, хотя, если это делает, это должно быть включено в кавычки. Любые внутренние кавычки в пределах text, вероятно, придется оставить.

- ссылка extdocURL

Создает ссылки к существующей javadoc-сгенерированной документации внешних классов, на которые ссылаются. Требуется один параметр:

• extdocURL является абсолютный или относительный URL каталога, содержащего внешнюю javadoc-сгенерированную документацию, с которой Вы хотите соединиться. Примеры показывают ниже. Файл списка пакета должен быть найден в этом каталоге (иначе, использовать -linkoffline). Инструмент Javadoc читает имена пакета из package-list файл и затем соединяется с теми пакетами в том URL. Когда инструмент Javadoc выполняется, значение extdocURL копируется буквально в <A HREF> ссылки, которые создаются. Поэтому, extdocURL должен быть URL к каталогу, не к файлу.

  Можно использовать абсолютную ссылку для extdocURL, чтобы позволить Вашим документам соединиться с документом о любом веб-сайте, или можно использовать относительную ссылку, чтобы соединиться только с относительным расположением. Если родственник, значение, в котором Вы передаете, должен быть относительным путем из целевого каталога (определенный с -d) к каталогу, содержащему пакеты, соединяемые с.

  Определяя абсолютную ссылку Вы обычно используете http: ссылка. Однако, если Вы хотите соединиться с файловой системой, у которой нет никакого веб-сервера, можно использовать a file: ссылка – однако, сделайте это, только если все желающие получить доступ к сгенерированной документации совместно используют ту же самую файловую систему.

  Во всех случаях, и на всех операционных системах, следует использовать наклонную черту вправо в качестве разделителя, является ли URL абсолютным или относительным, и "http:" или "файл:" базируемый (как определено в Записке URL).

  Абсолютный http: основанная ссылка:

  -link http://<host>/<directory>/<directory>/.../<name>

  Абсолютный файл: основанная ссылка:

  -link file://<host>/<directory>/<directory>/.../<name>

  Относительная ссылка:

  -link <directory>/<directory>/.../<name>

Можно определить многократный -link опции в данном javadoc, выполненном, чтобы соединиться с многократными документами.

Выбор между-linkoffline и - ссылка:
Использовать -link:

• при использовании относительного пути к внешнему документу API, или
• при использовании абсолютного URL к внешнему документу API, если Ваша оболочка позволяет программе открывать соединение с тем URL для того, чтобы читать.

Использовать -linkoffline:

• при использовании абсолютного URL к внешнему документу API, если Ваша оболочка не позволяет программе открывать соединение с тем URL для того, чтобы читать. Это может произойти, если Вы находитесь позади брандмауэра и документа, Вы хотите соединиться с, с другой стороны.

Пример используя абсолютные ссылки к внешним документам - Позволял нам говорить, что Вы хотите соединиться с java.lang, java.io и другой Java пакеты Платформы SE в http://docs.oracle.com/javase/7/docs/api/, Следующая команда генерирует документацию для пакета com.mypackage со ссылками к Java пакеты Платформы SE. Сгенерированная документация будет содержать ссылки к Object class, например, в деревьях class. (Другие опции, такой как -sourcepath и -d, не показываются.)

  C:> javadoc -link http://docs.oracle.com/javase/7/docs/api/ com.mypackage

Пример используя родственника соединяется с внешними документами - Скажем, у Вас есть два пакета, документы которых сгенерированы в различных выполнениях инструмента Javadoc, и те документы разделяются относительным путем. В этом примере пакеты com.apipackage, API, и com.spipackage, SPI (Служба Обеспечивают Интерфейс). Вы хотите, чтобы документация находилась в docs/api/com/apipackage и docs/spi/com/spipackage. Принятие документации пакета API уже сгенерировано, и это docs текущий каталог, Вы задокументировали бы пакет SPI со ссылками к документации API, работая:

  C:> javadoc -d ./spi -link ../api com.spipackage

Заметьте -link параметр относительно целевого каталога (docs/spi).

Детали - -link опция позволяет Вам соединиться с классами, на которые ссылается к Ваш код, но не задокументированные в ток javadoc выполненный. Для этих ссылок, чтобы пойти в допустимые страницы, следует знать, где те страницы HTML располагаются, и определяют то расположение с extdocURL. Это позволяет, например, сторонней документации соединяться с java.* документация относительно http://java.sun.com.

Опустите -link опция для javadoc, чтобы создать ссылки только к API в пределах документации это генерирует в выполненном токе. (Без -link опция, инструмент Javadoc не создает ссылки к документации для внешних ссылок, потому что это не знает, если или где та документация существует.)

Эта опция может создать ссылки в нескольких местах в сгенерированной документации.

Другое использование для перекрестных ссылок между наборами пакетов: Выполните javadoc на одном наборе пакетов, затем выполните javadoc снова на другом наборе пакетов, создавая ссылки оба пути между обоими наборами.

Как на Класс Нужно Сослаться - Для ссылки к внешнему class, на который ссылаются, чтобы фактически появиться (и не только его текстовая метка), на class нужно сослаться следующим образом. Не достаточно для этого быть сосланным в теле метода. На это нужно сослаться в любом import оператор или в объявлении. Вот примеры как class java.io.File может быть сослан:

• В любом отчасти import оператор: подстановочным импортом, импорт явно по имени, или автоматически импортируют для java.lang.*. Например, это было бы достаточно:
  import java.io.*;
  В 1.3.x и 1.2.x, только явный импорт по имени работает – подстановочный оператор импорта не работает, и при этом автоматическое не импортирует java.lang.*.
• В объявлении:
  void foo(File f) {}
  Ссылка и быть в типе возврата или типе параметра метода, конструктора, поля, class или интерфейса, или в implements, extends или throws оператор.

Важное заключение - это, когда Вы используете -link опция, может быть много ссылок, которые неумышленно не появляются из-за этого ограничения. (Текст появился бы без гипертекстовой ссылки.) Можно обнаружить их предупреждениями, которые они испускают. Самый безвредный способ должным образом сослаться на class и таким образом добавить ссылку состоял бы в том, чтобы импортировать тот class, как показано выше.

Список пакета - -link опция требует что названный файл package-list, который сгенерирован инструментом Javadoc, существуйте в URL, с которым Вы определяете -link. package-list файл является простым текстовым файлом, который перечисляет имена пакетов, задокументированных в том расположении. В более раннем примере инструмент Javadoc ищет названный файл package-list в данном URL, чтениях на имена пакета и затем соединяется с теми пакетами в том URL.

Например, список пакета для Java API SE располагается в http://docs.oracle.com/javase/7/docs/api/package-list и запускается следующим образом:

  java.applet
  java.awt
  java.awt.color
  java.awt.datatransfer
  java.awt.dnd
  java.awt.event
  java.awt.font
  etc.

Когда javadoc выполняется без -link опция, когда это встречается с именем, которое принадлежит внешнему class, на который ссылаются, он печатает имя без ссылки. Однако, когда -link опция используется, инструмент Javadoc ищет package-list файл в указанном extdocURL расположении для того имени пакета. Если это находит имя пакета, это префиксы имя с extdocURL.

Для там, чтобы быть никакими неработающими ссылками, вся документация для внешних ссылок должна существовать в указанных URL. Инструмент Javadoc не будет проверять, что эти страницы существуют – только, что список пакета существует.

Многократные Ссылки - можно предоставить многократный -link опции, чтобы соединиться с любым числом внешних сгенерированных документов. У Javadoc 1.2 есть известная ошибка, которая препятствует тому, чтобы Вы предоставили больше чем один -link команда. Это было фиксировано в 1.2.2.

Определите различную опцию ссылки для каждого внешнего документа, чтобы соединиться с:

  C:> javadoc -link extdocURL1 -link extdocURL2 ... -link extdocURLn com.mypackage

где extdocURL1, extdocURL2 ... extdocURLn указывают соответственно на корни внешних документов, каждый из которых содержит названный файл package-list.

Перекрестные ссылки - Примечание, что "начальная загрузка" может требоваться, перекрестный соединяя два или больше документа, которые не были ранее сгенерированы. Другими словами, если package-list не существует ни для одного документа, когда Вы выполняете инструмент Javadoc на первом документе, package-list еще не будет существовать для второго документа. Поэтому, чтобы создать внешние ссылки, следует регенерировать первый документ после генерирования второго документа.

В этом случае цель первого генерирования документа состоит в том, чтобы создать package-list (или можно создать это вручную это, если Вы уверены в именах пакета). Затем генерируйте второй документ с его внешними ссылками. Инструмент Javadoc печатает предупреждение если необходимое внешнее package-list файл не существует.

-linkoffline extdocURL packagelistLoc

Эта опция является изменением -link; они оба создают ссылки к javadoc-сгенерированной документации для внешних классов, на которые ссылаются. Используйте -linkoffline опция, соединяясь с документом о сети, когда инструмент самого Javadoc является "офлайновым" – то есть, он не может получить доступ к документу посредством веб-подключения.

Более определенно использовать -linkoffline если внешний документ package-list файл не доступен или не существует в extdocURL расположении, но действительно существует в различном расположении, которое может быть определено packageListLoc (обычно локальный). Таким образом, если extdocURL доступен только во всемирной паутине, -linkoffline удаляет ограничение, что у инструмента Javadoc есть веб-подключение, генерируя документацию.

Другое использование как "взлом", чтобы обновить документы: После того, как Вы выполнили javadoc на полном комплекте пакетов, тогда можно выполнить javadoc снова на onlya меньшем наборе измененных пакетов, так, чтобы обновленные файлы могли быть вставлены назад в исходный набор. Примеры даются ниже.

-linkoffline опция берет два параметра – первое для строки, которая будет встроена в <a href> ссылки, второе сообщение этого, где найти package-list:

• extdocURL является абсолютный или относительный URL каталога, содержащего внешнюю javadoc-сгенерированную документацию, с которой Вы хотите соединиться. Если родственник, значение должно быть относительным путем из целевого каталога (определенный с -d) к корню пакетов, соединяемых с. Для получения дополнительной информации см. extdocURL в -link опция.
• packagelistLoc является путем или URL к каталогу, содержащему package-list файл для внешней документации. Это может быть URL (http: или файл:) или путь к файлу, и может быть абсолютным или относительным. Если родственник, сделайте это относительно текущего каталога от того, куда javadoc был выполнен. Не включайте package-list имя файла.

Можно определить многократный -linkoffline опции в данном javadoc работают. (До 1.2.2, это могло быть определено только однажды.)

Пример используя абсолютные ссылки к внешним документам - Позволял нам говорить, что Вы хотите соединиться с java.lang, java.io и другой Java пакеты Платформы SE в http://docs.oracle.com/javase/7/docs/api/, но у Вашей оболочки нет веб-доступа. Вы могли открыться package-list файл в браузере в http://docs.oracle.com/javase/7/docs/api/package-list, сохраните это к локальному каталогу, и укажите на эту локальную копию со вторым параметром, packagelistLoc. В этом примере файл списка пакета был сохранен к текущему каталогу".". Следующая команда генерирует документацию для пакета com.mypackage со ссылками к Java пакеты Платформы SE. Сгенерированная документация будет содержать ссылки к Object class, например, в деревьях class. (Другие необходимые опции, такой как -sourcepath, не показываются.)

C:> javadoc -linkoffline http://docs.oracle.com/javase/7/docs/api/ . com.mypackage

Пример используя родственника соединяется с внешними документами - не очень распространено использовать -linkoffline с относительными путями, по простой причине это -link обычно достаточен. При использовании -linkoffline, package-list файл обычно локален, и при использовании относительных ссылок, файл, с которым Вы соединяетесь, также обычно локален. Таким образом, является обычно ненужным дать различный путь для этих двух параметров -linkoffline. Когда эти два параметра идентичны, можно использовать -link. См. -link относительный пример.

Вручную Создание a package-list Файл - Если a package-list файл еще не существует, но Вы знаете то, с чем именами пакета соединится Ваш документ, можно создать свою собственную копию этого файла вручную и определить его путь с packagelistLoc. Примером был бы предыдущий случай где список пакета для com.spipackage не существовал когда com.apipackage был сначала сгенерирован. Этот метод полезен, когда Вы должны генерировать документацию, которая соединяется с новой внешней документацией, имена пакета которой Вы знаете, но который еще не публикуется. Это - также способ создать package-list файлы для пакетов, сгенерированных с Javadoc 1.0 или 1.1, где package-list файлы не были сгенерированы. Аналогично, две компании могут совместно использовать свое неопубликованное package-list файлы, позволяя им выпустить их перекрестную соединенную документацию одновременно.

Соединяясь с Многократными Документами - можно включать -linkoffline однажды для каждого сгенерированного документа Вы хотите обратиться к (каждый вариант показывается на отдельной строке для ясности):

C:> javadoc -linkoffline extdocURL1 packagelistLoc1 \
          -linkoffline extdocURL2 packagelistLoc2 \
          ...

Обновление документов - Другое использование для -linkoffline опция полезна, если у Вашего проекта есть десятки или сотни пакетов, если Вы уже выполнили javadoc на всем дереве, и теперь, в отдельном выполнении, Вы хотите быстро сделать некоторые небольшие изменения и запустить повторно javadoc на только небольшой части исходного дерева. Это - своего рода взлом, в котором это работает должным образом, только если Ваши изменения только к комментариям документа а не к объявлениям. Если Вы должны были добавить, удалить или изменить какие-либо объявления от исходного кода, то неработающие ссылки могли обнаружиться в индексировании, дереве пакета, наследованных списках элементов, используйте страницу, и другие места.

Во-первых, Вы создаете новый целевой каталог (вызовите его update) для этого нового маленького выполнения. Скажем, исходный целевой каталог назвали html. В самом простом примере, cd к родителю html. Установите первый параметр -linkoffline к текущему каталогу "." и набору второй параметр относительному пути к html, где это может найти package-list, и передача на только имена пакета пакетов Вы хотите обновить:

  C:> javadoc -d update -linkoffline . html com.mypackage

Когда инструмент Javadoc делается, скопируйте, они генерировали страницы class в update\com\package (не краткий обзор или индексируют), по исходным файлам в html\com\package.

-linksource 

Создает версию HTML каждого исходного файла (с номерами строки) и добавляет ссылки им из стандартной документации HTML. Ссылки создаются для классов, интерфейсов, конструкторов, методов и полей, объявления которых находятся в исходном файле. Иначе, ссылки не создаются, такой что касается конструкторов по умолчанию и сгенерированных классов.

Эта опция представляет все частные детали реализации во включенных исходных файлах, включая частные классы, частные поля, и тела закрытых методов, независимо от -public, -package, -protected и -private опции. Если Вы также не используете -private опция, не все частные классы или интерфейсы обязательно будут доступны через ссылки.

Каждая ссылка появляется на имени идентификатора в его объявлении. Например, ссылка к исходному коду Button class был бы на слове "Button":

    public class Button
    extends Component
    implements Accessible

и ссылка к исходному коду getLabel() метод в Кнопке class был бы на слове "getLabel":

    public String getLabel()

- группа groupheading packagepattern:packagepattern:...

Разделяет пакеты на странице краткого обзора в любые группы, которые Вы определяете, одна группа на таблицу. Вы определяете каждую группу с различным -group опция. Группы появляются на странице в порядке, определенном на командной строке; пакеты располагаются в алфавитном порядке в пределах группы. Для данного -group опция, пакеты, соответствующие список выражений packagepattern, появляется в таблице с возглавляющим groupheading.

• groupheading может быть любым текстом, и может включать пробел. Этот текст помещается в таблицу, движущуюся к группе.
• packagepattern может быть любым именем пакета, или может быть запуском любого имени пакета, сопровождаемого звездочкой (*). Звездочка является подстановочным знаком, означающим "соответствие любые символы". Это - единственный позволенный подстановочный знак. Многократные образцы могут быть включены в группу, разделяя их с двоеточиями (:).

ОТМЕТЬТЕ: используя звездочку в образце или списке образца, список образца должен быть внутренними кавычками, такой как "java.lang*:java.util"

Если Вы не предоставляете никого -group опция, все пакеты помещаются в одну группу с возглавляющими "Пакетами". Если все группы не включают все задокументированные пакеты, любые оставшиеся пакеты появляются в разделять группе с заголовком "Других Пакетов".

Например, следующая опция разделяет четыре задокументированных пакета на ядро, расширение и другие пакеты. Заметьте, что запаздывающая "точка" не появляется в "java.lang *" – включая точку, такой, поскольку "java.lang. *" опустил бы java.lang пакет.

  C:> javadoc -group "Core Packages" "java.lang*:java.util"
            -group "Extension Packages" "javax.*"
            java.lang java.lang.reflect java.util javax.servlet java.new

Это приводит к группировкам:

Базовые Пакеты

java.lang

java.lang.reflect

java.util

Пакеты расширения

javax.servlet

Другие Пакеты

java.new

-nodeprecated

Предотвращает генерацию любого осуждаемого API вообще в документации. Это делает то, что делает-nodeprecatedlist, плюс это не генерирует осуждаемого API всюду по остальной части документации. Это полезно при записи кода, и Вы не хотите быть отвлеченными осуждаемым кодом.

-nodeprecatedlist

Предотвращает генерацию файла, содержащего список осуждаемых API (deprecated-list.html) и ссылки в панели навигации к той странице. (Однако, javadoc продолжает генерировать осуждаемый API всюду по остальной части документа.) Это полезно, если Ваш исходный код не содержит осуждаемого API, и Вы хотите сделать уборщика панели навигации.

-nosince

Опускает из сгенерированных документов "Начиная с" разделов, связанных с тегами @since.

-notree

Опускает class / страницы иерархии интерфейса из сгенерированных документов. Они - страницы, Вы достигаете использования кнопки "Tree" в панели навигации. Иерархия производится по умолчанию.

-noindex

Опускает индексирование из сгенерированных документов. Индексирование производится по умолчанию.

-nohelp

Опускает ссылку СПРАВКИ в панелях навигации вверху и внизу каждой страницы вывода.

-nonavbar

Предотвращает генерацию панели навигации, заголовка и нижнего колонтитула, иначе найденного вверху и внизу сгенерированных страниц. Имеет не влияют на "нижней" опции. -nonavbar опция полезна, когда Вы интересуетесь только контентом и не имеете никакой потребности в навигации, такой как преобразование файлов к PostScript или PDF для печати только.

-helpfile path\filename

Определяет путь альтернативного справочного файла path\filename, с которым соединяется ссылка СПРАВКИ в вершине и нижних панелях навигации. Без этой опции инструмент Javadoc автоматически создает справочный файл help-doc.html это трудно кодируется в инструменте Javadoc. Эта опция позволяет Вам переопределить это значение по умолчанию. Имя файла может быть любым именем и не ограничивается help-doc.html – инструмент Javadoc скорректирует ссылки в панели навигации соответственно. Например:

  C:> javadoc -helpfile C:\user\myhelp.html java.awt

-stylesheetfile path\filename

Определяет путь альтернативного файла таблицы стилей HTML. Без этой опции инструмент Javadoc автоматически создает файл таблицы стилей stylesheet.css это трудно кодируется в инструменте Javadoc. Эта опция позволяет Вам переопределить это значение по умолчанию. Имя файла может быть любым именем и не ограничивается stylesheet.css. Например:

  C:> javadoc -stylesheetfile C:\user\mystylesheet.css com.mypackage

-serialwarn

Генерирует предупреждения времени компиляции для того, чтобы пропустить теги @serial. По умолчанию Javadoc 1.2.2 (и более поздние версии) не генерирует последовательных предупреждений. (Это - реверсирование от более ранних версий.) Используют эту опцию, чтобы вывести на экран последовательные предупреждения, который помогает должным образом задокументировать значение по умолчанию сериализуемые поля и writeExternal методы.

- имя набора символов

Определяет набор символов HTML для этого документа. Имя должно быть привилегированным именем MIME как дано в Реестре IANA. Например:

  C:> javadoc -charset "iso-8859-1" mypackage

вставил бы следующую строку в главу каждой сгенерированной страницы:

   <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">

Этот тег МЕТЫ описывается в стандарте HTML. (4197265 и 4137321)

Также см. - кодирование и-docencoding.

 Имя-docencoding

Определяет кодирование сгенерированных файлов HTML. Имя должно быть привилегированным именем MIME как дано в Реестре IANA. Если Вы опускаете эту опцию, но использование - кодирование, то кодирование сгенерированных файлов HTML определяется - кодирование. Пример:

  % javadoc -docencoding "ISO-8859-1" mypackage

Также см. - кодирование и - набор символов.

- ключевые слова

Добавляет HTML meta теги ключевого слова к сгенерированному файлу для каждого class. Эти теги могут помочь странице быть найденными поисковыми системами, которые ищут теги meta. (Большинство поисковых систем, которые ищут весь Интернет, не смотрит на теги meta, потому что страницы могут неправильно использовать их; но поисковые системы, предлагаемые компаниями, которые ограничивают их поиск их собственным сайтом, могут извлечь выгоду, смотря meta теги.)

Теги meta включают полностью определенное имя class и неполные имена полей и методов. Конструкторы не включаются, потому что они идентичны имени class. Например, Строка class запускается с этих ключевых слов:

     <META NAME="keywords" CONTENT="java.lang.String class">
     <META NAME="keywords" CONTENT="CASE_INSENSITIVE_ORDER">
     <META NAME="keywords" CONTENT="length()">
     <META NAME="keywords" CONTENT="charAt()">

- тег  tagname:Xaoptcmf:"taghead"

Позволяет инструменту Javadoc интерпретировать простую, пользовательскую метку блока с одним параметром @tagname в комментариях документа. Таким образом, инструмент Javadoc может "проверить орфографию" имен тега, важно включать a -tag опция для каждого пользовательского тега, который присутствует в исходном коде, отключая (с X) те, которые не выводятся в выполненном токе.

Двоеточие (:) всегда разделитель. Чтобы использовать двоеточие в tagname, см. Использование Двоеточия на Имя тега.

-tag опция выводит заголовок тега taghead полужирным, последовал следующая строка текстом от его единственного параметра, как показано в примере ниже. Как любая метка блока, текст этого параметра может содержать встроенные теги, которые также интерпретируются. Вывод подобен стандартным тегам с одним параметром, такой как @return и @author. Исключение taghead заставляет tagname появляться как заголовок.

Размещение тегов - Xaoptcmf часть параметра определяет, где в исходном коде тегу позволяют быть помещенным, и может ли тег быть запрещен (использование X). Можно предоставить также a, позволить тег во всех местах, или любую комбинацию других букв:

X (отключите тег),
a (все)
o (краткий обзор)
p (пакеты)
t (типы, который является классами и интерфейсами),
c (конструкторы)
m (методы)
f (поля)

Примеры единственных тегов - пример опции тега для тега, который может использоваться где угодно в исходном коде:

-tag todo:a:"To Do:"

Если бы Вы хотели, чтобы использовался только с конструкторами, методами и полями, то Вы использовали бы:

-tag todo:cmf:"To Do:"

Заметьте последнее двоеточие (:) выше не разделитель параметра, но часть возглавляющего текста (как показано ниже). Вы использовали бы любую опцию тега для исходного кода, который содержит тег @todo, такой как:

@todo The documentation for this method needs work.

Эта строка произвела бы, выводит что-то как:

To Do:
      The documentation for this method needs work.

Использование Двоеточия на Имя тега - двоеточие может использоваться на имя тега, если этого оставляют с наклонной чертой влево. Для этого комментария документа:

    /**
     * @ejb:bean
     */

используйте эту опцию тега:

    -tag ejb\:bean:a:"EJB Bean:"

Имена тега проверки орфографии (Запрещающий теги) - Некоторые разработчики помещенные пользовательские теги в исходном коде, который они не всегда хотят вывести. В этих случаях важно перечислить все теги, которые присутствуют в исходном коде, включая тем Вы хотите вывести и отключение тех, Вы не хотите выводить. Присутствие X отключает тег, в то время как его отсутствие включает тегу. Это дает инструменту Javadoc достаточную информацию, чтобы знать, неизвестен ли тег, с которым это встречается, вероятно результаты опечатки или орфографической ошибки. Это печатает предупреждение в этих случаях.

Можно добавить X к значениям размещения уже представляют, так, чтобы, когда Вы хотите включить тегу, можно было просто удалить X. Например, если @todo является тегом, который Вы хотите подавить на выводе, Вы использовали бы:

    -tag todo:Xcmf:"To Do:"

или, если Вы сохранили бы это простым:

    -tag todo:X

Синтаксис -tag todo:X работы, даже если @todo определяется taglet.

Порядок тегов - порядок -tag (и -taglet) опции определяют порядок, теги выводятся. Можно смешать пользовательские теги со стандартными тегами, чтобы вкрапить их. Опции тега для стандартных тегов являются заполнителями только для того, чтобы определить порядок – они берут только имя стандартного тега. (Подзаголовки для стандартных тегов не могут быть изменены.) Это иллюстрируется в следующем примере.

Если -tag отсутствует, тогда позиция -taglet определяет его порядок. Если они оба существуют, то, какой бы ни кажется последним на командной строке, определяет ее порядок. (Это происходит, потому что теги и taglets обрабатываются в порядке, что они появляются на командной строке. Например, если -taglet и -tag у обоих есть имя "todo", тот, который кажется последним на командной строке, определит свой порядок.

Пример полного набора тегов - Этот пример вставляет, "Чтобы Сделать" после "Параметров" и перед "Бросками" в выводе. При использовании "X", это также определяет, что @example является тегом, с которым можно было бы встретиться в исходном коде, который не должен быть выведен во время этого выполнения. Заметьте, что, если Вы используете @argfile, можно поместить теги в отдельные строки в файле параметра как это (никакие необходимые символы продолжения строки):

   -tag param
   -tag return
   -tag todo:a:"To Do:"
   -tag throws
   -tag see
   -tag example:X

Когда javadoc анализирует комментарии документа, любой тег, с которым встречаются, который не является ни стандартным тегом, ни передал в с -tag или -taglet считается неизвестным, и предупреждение бросается.

Стандартные теги первоначально сохранены внутренне в списке в их порядке значения по умолчанию. Всякий раз, когда -tag опции используются, те теги добавляются к этому списку – стандартные теги перемещаются от их позиции значения по умолчанию. Поэтому, если a -tag опция опускается для стандартного тега, это остается в его позиции значения по умолчанию.

Уход от Конфликтов - Если Вы хотите нарезать свое собственное пространство имен, можно использовать разделенное от точки соглашение о присвоении имен, подобное используемому для пакетов: com.mycompany.todo. Sun будет продолжать создавать стандартные теги, имена которых не содержат точки. Любой тег, который Вы создаете, переопределит поведение тега тем же самым именем, определенным Sun. Другими словами, если Вы создаете тег или taglet @todo, у этого всегда будет то же самое поведение, которое Вы определяете, даже если Sun позже создает стандартный тег того же самого имени.

Аннотации по сравнению с Тегами Javadoc - Вообще, если разметка Вы хотите добавить, предназначаются, чтобы влиять или произвести документацию, это должен, вероятно, быть тег javadoc; иначе, это должна быть аннотация. См. Сравнение Теги Javadoc и Аннотации

Можно также создать более сложные метки блока, или пользовательские встроенные теги с-taglet опцией.

-taglet  class

Определяет файл class, который запускает taglet, используемый в генерировании документации для того тега. Используйте полностью определенное имя для class. Этот taglet также определяет число текстовых параметров, что пользовательский тег имеет. taglet принимает те параметры, обрабатывает их, и генерирует вывод. Для обширной документации с примером taglets, см.:

• Краткий обзор Taglet

Taglets полезны для блока или встраивают теги. Они могут иметь любое число параметров и реализовать пользовательское поведение, такое как создание текста полужирные, форматирующие маркеры, выписывание текст к файлу, или запуск других процессов.

Taglets может только определить, где тег должен появиться и в какой форма. Все другие решения принимаются doclet. Таким образом, taglet не может сделать вещей тех, которые удаляют имя class из списка включенных классов. Однако, это может выполнить побочные эффекты, такие как печать текста тега к файлу или инициированию другого процесса.

Используйте -tagletpath опция, чтобы определить путь к taglet. Вот пример, который вставляет, "Чтобы Сделать" taglet после "Параметров" и перед "Бросками" в сгенерированных страницах:

    -taglet com.sun.tools.doclets.ToDoTaglet
    -tagletpath /home/taglets
    -tag return
    -tag param
    -tag todo
    -tag throws
    -tag see

Альтернативно, можно использовать -taglet опция вместо -tag опция, но это может быть более трудно считать.

-tagletpath  tagletpathlist

Определяет пути поиска для того, чтобы найти taglet файлы class (.class). tagletpathlist может содержать разнообразные пути, разделяя их двоеточием (:). Инструмент Javadoc будет искать во всех подкаталогах указанных путей.

-docfilessubdirs 

Позволяет глубоко копировать"doc-files"каталоги. Другими словами подкаталоги и все содержание рекурсивно копируются в место назначения. Например, каталог doc-files/example/images и все его содержание было бы теперь скопировано. Есть также опция, чтобы исключить подкаталоги.

-excludedocfilessubdir  name1:name2...

Исключает любого"doc-files"подкаталоги с именами. Это предотвращает копирование SCCS и других подкаталогов управления исходным кодом.

-noqualifier  all |  packagename1:packagename2:...

Опускает квалифицировать имя пакета от перед именами class в выводе. Параметр -noqualifier любой"all"(все спецификаторы пакета опускаются), или отдельный от двоеточия список пакетов, с подстановочными знаками, чтобы быть удаленным как спецификаторы. Имя пакета удаляется из мест, где class или имена интерфейса появляются.

Следующий пример опускает все спецификаторы пакета:

    -noqualifier all

Следующий пример опускает "java.lang" и "java.io" спецификаторы пакета:

    -noqualifier java.lang:java.io

Следующий пример опускает спецификаторы пакета, запускающиеся с "java", и "com.sun" подпакетов (но не "javax"):

    -noqualifier java.*:com.sun.*

Где спецификатор пакета появился бы из-за вышеупомянутого поведения, имя может быть соответственно сокращено – видят, Как имя выводится на экран. Это правило состоит в действительности в том действительно ли -noqualifier используется.

-notimestamp 

Подавляет метку времени, которая скрывается в комментарии HTML в сгенерированном HTML около вершины каждой страницы. Полезный, когда Вы хотите выполнить javadoc на двух исходных основах и разности их, поскольку это препятствует тому, чтобы метки времени вызвали разность (который иначе был бы разностью на каждой странице). Метка времени включает javadoc номер версии, и в настоящий момент похожа на это:

     <!-- Generated by javadoc (build 1.5.0_01) on Thu Apr 02 14:04:52 IST 2009 -->

-nocomment 

Подавите все тело комментария, включая основное описание и все теги, генерируя только объявления. Эта опция позволяет снова использовать исходные файлы, первоначально предназначенные в различной цели, произвести скелетную документацию HTML на ранних стадиях нового проекта.

-sourcetab tabLength

Определите число пробелов, которые каждая вкладка приводит в рабочее состояние в источнике.

ФАЙЛЫ ПАРАМЕТРА КОМАНДНОЙ СТРОКИ

Файл параметра может включать javadoc опции и исходные имена файлов в любой комбинации. Параметры в пределах файла могут быть разделены пробелом или разделены от новой строки. Если имя файла содержит встроенные пробелы, помещало целое имя файла в двойные кавычки, и удваивает каждую наклонную черту влево ("My Files\\Stuff.java").

Имена файлов в пределах файла параметра относительно текущего каталога, не расположения файла параметра. Подстановочные знаки (*) не позволяются в этих списках (такой что касается определения *.java). Использование символа '@', чтобы рекурсивно интерпретировать файлы не поддерживается. -J опции не поддерживаются, потому что их передают к средству запуска, которое не поддерживает файлы параметра.

Выполняясь javadoc, передайте в пути и имени каждого файла параметра с '@' ведущий символ. Когда javadoc встречается с параметром, начинающимся с символьного `@', он разворачивает содержание того файла в список параметров.

Пример - Единственный Файл Аргумента

  C:> javadoc @argfile

Пример - Два Файла Аргумента

Создайте файл, названный"options"содержа:

     -d docs-filelist 
     -use 
     -splitindex
     -windowtitle 'Java SE 7 API Specification'
     -doctitle 'Java SE 7 API Specification'
     -header '<b>Java™ SE 7</b>'
     -bottom 'Copyright &copy; 1993-2011 Oracle and/or its affiliates. All rights reserved.'
     -group "Core Packages" "java.*"
     -overview \java\pubs\ws\1.7.0\src\share\classes\overview-core.html
     -sourcepath \java\pubs\ws\1.7.0\src\share\classes

Создайте файл, названный"packages"содержа:

     com.mypackage1
     com.mypackage2
     com.mypackage3

  C:> javadoc @options @packages

Пример - Файлы Аргумента с Путями

  C:> javadoc @path1\options @path2\packages

Пример - Параметры Опции

Вот пример сохранения только параметра javadoc опции в файле параметра. Мы будем использовать -bottom опция, так как у этого может быть длинный параметр. Вы могли создать файл, названный"bottom"содержа его текстовый параметр:

'<font size="-1">
      <a href="http://bugreport.sun.com/bugreport/">Submit a bug or feature</a><br/>
      Copyright &copy; 1993, 2011, Oracle and/or its affiliates. All rights reserved.<br/>
      Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
      Other names may be trademarks of their respective owners.</font>'

  C:> javadoc -bottom @bottom @packages

  C:> javadoc @bottom @packages

Выполнение

ВЫПОЛНЕНИЕ JAVADOC

Общедоступный программируемый интерфейс - Чтобы вызвать инструмент Javadoc изнутри программ, записанных на языке Java. Этот интерфейс находится в com.sun.tools.javadoc.Main (и javadoc повторно используем). Для получения дополнительной информации см. Стандартный Doclet.

Выполняя Doclets - инструкции, данные ниже, для того, чтобы вызвать стандартный HTML doclet. Чтобы вызвать пользовательский doclet, используйте-doclet и-docletpath опции. Для полных, рабочих примеров выполнения определенного doclet см. MIF Doclet документация.

ПРОСТЫЕ ПРИМЕРЫ

Документирование Одного или Более Пакетов

Можно выполнить javadoc любой, изменяя каталоги (с cd) или при использовании -sourcepath опция. Примеры ниже иллюстрируют обе альтернативы.

• Случай 1 - Выполнение, рекурсивно запускающееся с одного или более пакетов - Этот пример использует-sourcepath, таким образом, javadoc может быть выполнен из любого каталога и-subpackages (новые 1.4 опции) для рекурсии. Это пересекает подпакеты java каталог, исключая пакеты базировался в java.net и java.lang. Заметьте, что это исключает java.lang.ref, подпакет java.lang).

    % javadoc -d \home\html -sourcepath \home\src -subpackages java -exclude java.net:java.lang
  

  Чтобы также пересечь вниз другие деревья пакета, добавьте их имена к -subpackages параметр, такой как java:javax:org.xml.sax.

• Случай 2 - Работавший явные пакеты после изменения на "корневой" исходный каталог - Изменение к родительскому каталогу полностью определенного пакета. Затем выполненный javadoc, предоставляя имена одного или более пакетов Вы хотите задокументировать:

    C:> cd C:\home\src\
    C:> javadoc -d C:\home\html java.awt java.awt.event
  

• Случай 3 - Выполнение из любого каталога на явных пакетах в единственном дереве каталогов - В этом случае, не имеет значения, каков текущий каталог. Выполненное предоставление javadoc -sourcepath с родительским каталогом высокоуровневого пакета, и именами предоставления одного или более пакетов Вы хотите задокументировать:

    C:> javadoc -d C:\home\html -sourcepath C:\home\src java.awt java.awt.event
  

• Случай 4 - Выполнение из любого каталога на явных пакетах в многократных деревьях каталогов - Это - то же самое как случай 3, но для пакетов в отдельных деревьях каталогов. Выполненное предоставление javadoc -sourcepath с путем к (разделенному от двоеточия) корню каждого дерева и имена предоставления одного или более пакетов Вы хотите задокументировать. Все исходные файлы для данного пакета не должны быть расположены под единственным корневым каталогом – они только должны быть найдены где-нибудь вдоль sourcepath.

    C:> javadoc -d C:\home\html -sourcepath C:\home\src1;C:\home\src2 java.awt java.awt.event
  

Документирование Одного или Более Классов

• Случай 1 - Изменяющийся на исходный каталог - Изменение к каталогу, содержащему .java файлы. Затем выполненный javadoc, предоставляя имена одного или более исходных файлов Вы хотите задокументировать.

    C:> cd C:\home\src\java\awt
    C:> javadoc -d C:\home\html Button.java Canvas.java Graphics*.java
  

  Этот пример генерирует отформатированную HTML документацию для классов Button, Canvas и начинающиеся классы Graphics. Поскольку в исходных файлах, а не именах пакета передали как параметры javadoc, у документа есть два фрейма – для списка классов и основной страницы.
• Случай 2 - Изменяющийся на корневой каталог пакета - Это полезно для документирования отдельных исходных файлов от различных подпакетов от того же самого корня. Изменитесь на корневой каталог пакета, и предоставьте исходные файлы пути от корня.

    C:> cd C:\home\src
    C:> javadoc -d \home\html java\awt\Button.java java\applet\Applet.java
  

  Этот пример генерирует отформатированную HTML документацию для классов Button и Applet.
• Случай 3 - Из любого каталога - В этом случае, не имеет значения, каков текущий каталог. Выполненный javadoc предоставление абсолютного пути (или путь относительно текущего каталога) к .java файлы Вы хотите задокументировать.

    C:> javadoc -d C:\home\html C:\home\src\java\awt\Button.java C:\home\src\java\awt\Graphics*.java
  

  Этот пример генерирует отформатированную HTML документацию для class Button и начинающиеся классы Graphics.

Документирование И Пакеты и Классы

  C:> javadoc -d C:\home\html -sourcepath C:\home\src java.awt C:\home\src\java\applet\Applet.java

ПРИМЕР РЕАЛЬНОГО МИРА

Тот же самый пример показывают дважды – сначала столь же выполняемый на командной строке, затем как выполняющийся от make-файла. Это использует абсолютные пути в параметрах опции, который включает тому же самому javadoc команда, которая будет выполнена из любого каталога.

Пример Командной строки

C:\> javadoc -sourcepath \java\jdk\src\share\classes ^
    -overview \java\jdk\src\share\classes\overview.html ^
    -d \java\jdk\build\api ^
    -use ^
    -splitIndex ^
    -windowtitle 'Java Platform, Standard Edition 7 API Specification' ^
    -doctitle 'Java Platform, Standard Edition 7 API Specification' ^
    -header '<b>Java™ SE 7</b>' ^
    -bottom '<font size="-1">
      <a href="http://bugreport.sun.com/bugreport/">Submit a bug or feature</a><br/>
      Copyright &copy; 1993, 2011, Oracle and/or its affiliates. All rights reserved.<br/>
      Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
      Other names may be trademarks of their respective owners.</font>'
    -group "Core Packages" "java.*:com.sun.java.*:org.omg.*" ^
    -group "Extension Packages" "javax.*" ^
    -J-Xmx180m ^  
    @packages

Пример make-файла

javadoc -sourcepath $(SRCDIR)              ^   /* Sets path for source files     */
        -overview $(SRCDIR)\overview.html  ^   /* Sets file for overview text    */
        -d \java\jdk\build\api             ^   /* Sets destination directory     */
        -use                               ^   /* Adds "Use" files               */
        -splitIndex                        ^   /* Splits index A-Z               */
        -windowtitle $(WINDOWTITLE)        ^   /* Adds a window title            */
        -doctitle $(DOCTITLE)              ^   /* Adds a doc title               */
        -header $(HEADER)                  ^   /* Adds running header text       */
        -bottom $(BOTTOM)                  ^   /* Adds text at bottom            */
        -group $(GROUPCORE)                ^   /* 1st subhead on overview page   */
        -group $(GROUPEXT)                 ^   /* 2nd subhead on overview page   */
        -J-Xmx180m                         ^   /* Sets memory to 180MB           */
        java.lang java.lang.reflect        ^   /* Sets packages to document      */
        java.util java.io java.net         ^
        java.applet

WINDOWTITLE = 'Java™ Platform, Standard Edition 6 API Specification'
DOCTITLE = 'Java™ Platform, Standard Edition 6 API Specification'
HEADER = '<b>Java™ Platform, Standard Edition 6'
BOTTOM = '<font size="-1">
      <a href="http://bugreport.sun.com/bugreport/">Submit a bug or feature</a><br/>
      Copyright &copy; 1993, 2011, Oracle and/or its affiliates. All rights reserved.<br/>
      Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
      Other names may be trademarks of their respective owners.</font>'
GROUPCORE = '"Core Packages" "java.*:com.sun.java.*:org.omg.*"'
GROUPEXT  = '"Extension Packages" "javax.*"'
SRCDIR = '/java/jdk/1.7.0/src/share/classes'

Одинарные кавычки используются, чтобы окружить параметры make-файла.

ПРИМЕЧАНИЯ

• Если Вы опускаете -windowtitle опция, инструмент Javadoc копирует документ title в окно title. -windowtitle текст является в основном тем же самым как -doctitle но без HTML-тэгов, чтобы препятствовать тому, чтобы те теги казались как необработанный текст в окне title.
• Если Вы опускаете -footer опция, как сделано здесь, инструмент Javadoc копирует текст заголовка в нижний колонтитул.
• Другие важные опции, которые Вы могли бы хотеть использовать, но не необходимые в этом примере, -classpath и -link.

ПОИСК И УСТРАНЕНИЕ НЕИСПРАВНОСТЕЙ

Общий Поиск и устранение неисправностей

• FAQ Javadoc - Обычно встреченные ошибки и подсказки по поиску и устранению неисправностей могут быть найдены на FAQ Javadoc
• Ошибки и Ограничения - можно также видеть некоторые ошибки, перечисленные в Важных Исправлениях ошибок и Изменениях.
• Номер версии - Видит номера версий.
• Документы только юридические классы - документируя пакет, javadoc только читает файлы, имена которых составляются из юридических имен class. Можно препятствовать тому, чтобы javadoc анализировал файл включением, например, дефисом "-" в его имени файла.

Ошибки и Предупреждения

• "error: cannot read: Class1.java" инструмент Javadoc пытается загрузить class Class1.java в текущем каталоге. Имя class показывают с его путем (абсолютный или относительный), который в этом случае является тем же самым как ./Class1.java.

СРЕДА

CLASSPATH

Переменная окружения, которая обеспечивает путь который использование javadoc найти пользователя файлами class. Эта переменная окружения переопределяется -classpath опция. Разделите каталоги точкой с запятой, например:

.; C:\classes; C:\home\java\classes

СМ. ТАКЖЕ

• javac
• java
• jdb
• javah
• javap
• Домашняя страница Javadoc
• Как Записать Комментарии Документа для Javadoc
• Установка Пути к классу
• Как Javac и Javadoc Находят Классы (tools.jar)

---

Авторское право © 1993, 2012, Oracle и/или его филиалы. Все права защищены.

Свяжитесь с Нами