The "File" menu provides options for loading/saving the current project settings. In addition, the currently opened project name is displayed in the JCC window's title bar (see Figure 2.1, “JCC window”). The "File/Settings" menu item allows to open the platform settings dialog described in Section 2.2, “Platform Settings”. The "File/Exit" menu item allows to close the GUI and kill the JCC agent, and optionally shutdown the whole platform. The "Help" menu provides access to the Jadex help system and the Jadex homepage.

The buttons at the right side of the toolbar allow to switch between the perspectives provided by the plugins (starter, introspector, conversation center, and tracer). The buttons on the left as well as all menus except "File" and "Help" are dependent on the selected perspective and will be described there.

Figure 2.1. JCC window

The settings dialog available from the "File" menu is used to set up diverse options for the Jadex platform and agent loading process. It is shown below in the Figure 2.2, “Platform settings dialog” and includes following options.

Expression evaluation.  Jadex provides several options how to evaluate the Java expressions contained in ADFs. The built in interpreter features fast loading times, but limited runtime performance, as the Java statements have to be interpreted on every access. The interpreter allows to restart plan classes, when they have changed. This allows to try out a change in the Java code without having to reload the platform. Note, that this feature should only used for debugging, as it slows down the system. The alternative to the interpreter is the online compiler based on Janino, which is available from the Jadex homepage as an add-on. In order to further speed up the process of agent loading and execution, the compiled expressions may be saved directly to a cache file. The options Write to file-cache enabled and Read from file-cache enabled activate this behaviour.

XML model loading.  The XML model loading section allows to influence how Jadex loads agent and capability models. When integrity checking is enabled all loaded agent and capability models are checked against a set of consistency rules (syntax of Java expressions, validity of cross references between goals and plans, etc.). The platform will refuse to start invalid agent models. The feature can be disabled to improve performance in deployed applications. To actually process the ADF and load the agent model, Jadex uses one of two XML-databinding frameworks. JiBX is a fast loader with a low memory footprint. To further improve performance the option to cache loaded models is available, which results in even faster loading times. JBind is a sophisticated mapping framework with the possibility to generate Java classes directly from the XML schema specification. Therefore JBind is the framework of choice for development purposes involving frequent changes to the XML schema.

Figure 2.2. Platform settings dialog

View refresh.  In addition to the standard start and stop functionalities the model tree also supports more advanced features. If not explicitly turned off in the Model menu the tree is automatically refreshed in certain time intervals. This means that changes on hard-disk are immediately reflected within the model tree. You can also initiate a refreshment directly by clicking the button.

Integrity checking.  In addition all models found in the tree are automatically checked for integrity if this feature isn't turned off in the Model menu. This feature allows to effortlessly locate corrupt agent and capability files in the project. If a corrupt file is found, the file as well as all packages up to the root are marked as corrupt. A corrupt entity is displayed with a red bolt .

Jadexdoc generation.  The Jadexdoc tool allows to generate documentation for agents in a style similar to Javadoc for Java classes. You can invoke the Jadexdoc generation dialog directly from the starter perspective via the button from the toolbar. If you previously have selected an agent or capability model or a package in the model tree this information will be passed to the dialog. The dialog will show this entry as "selected package". After the generation process the HTML output can be opened automatically in a browser. For details about the available options please refer to Chapter 8, Jadexdoc Tool.

The Running Agents panel shows all currently alive agents of the platform. For each agent its name and the first transport address is shown. To kill an agent it has first to be selected. Thereafter the kill action can be invoked via the popup menu or the toolbar .

Besides killing agents also the whole platform can be shutdowned via the button .

In the Model Panel details of a loaded agent or capability are shown. A model can be loaded either by selecting a file from the Model Tree or by using the "..." button to browse for a certain file. For a selected model several properties are presented:

If an agent model could be loaded without errors you can start a new agent instance of this model simply by hitting the Start button. If you changed a model you can load it from model again with the Reload button. The Reset button can be used to clear all fields and discard all loaded models from cache. Finally, the help button allows to invoke the online JavaHelp.

Three base panels show the beliefs (), goals (), and plans () respectively. They are very similar in their usage (see Figure 4.2, “The Beliefs Panel of Introspector”). All elements are shown in a tree structure representing the containment hierarchy of the elements in the capabilities of the agent.

Figure 4.2. The Beliefs Panel of Introspector

The different elements of the agent are shown with different icons as explained in Table 4.1, “Introspector Base Panel Elements”. For each element the most important attributes are displayed directly in the tree/table structure. The content of the base panels will automatically be updated when changes occur inside the agent.

The tree component allows nodes to be closed to focus on interesting subsets of the agent's functionality. The column widths can be (auto-) adjusted by dragging or double-clicking between the column headers. The table headers also provide a popup->menu (opened with right-click) that allows to hide some of the columns for better readability. You can double click on the elements to see more detailed information. The details panel is not automatically updated, you may have to double click the element again, to see up to date information.

You can to some extent manipulate the elements shown in the base panels. E.g. you can alter the values of facts in the beliefbase. Double click on the fact value you wish to change (in the value column), and then enter the new value as Java expression (i.e "text" for a string value). The expressions are evaluated using the imports as specified in the ADF (of the corresponding capability) therefore you can write expressions just as you would do that in a <fact> tag of the ADF. In addition, popup menus are available e.g. to remove beliefs, terminate plans or change the state of goals.

Some options are available to influence the appearance of the base panels (see Table 4.2, “Introspector Base Panel Options”). It is possible to deactivate (and later resume) the observation of any tab independently, by right-clicking on the tab's title. The observed agent will continue to execute, but changes will not be reflected in the panel until the observation is resumed. To pause the execution of the observed agent use the debugger panel described in the next section.

The resize icon allows to auto-adjust the widths of the table columns to fit the displayed content. The next two icons are concerned with the presentation of removed elements. Because the final state of a goal or a plan may be of interest after the goal has been dropped or the plan has terminated, the panels have an option not to remove those elements from the representation, but just visually mark them as removed. This is especially useful for debugging your agents, e.g. in conjunction with the debugger view described in the next section. To flush removed beliefs, goals and plans from the representation, you can use the waste bin icon.

The last icon is only available in the goalbase panel. It allows to switch between the goalview and the planview representation of the agent's current goals. The goalview, shown by default, displays only the proprietary goals (not the process goals created for each executed plan). The goals are arranged in the goal/subgoal hierarchy, i.e. a subgoal of a plan is shown as a subnode of the goal for which the plan is executed. Although this shows the goal hierarchy as expected, this is not how it is actually constructed inside the agent. The goalview hides that for each plan execution a process goal is created as a copy of the original goal. Subgoals dispatched by plans are actually created as subgoals of the process goal and not of the proprietary goal. For plans that are executed in reaction to internal or message events a dummy goal is created, which is also hidden in the goalview. Both views are compared in Figure 4.3, “Goalview and planview”. In the planview you can see that the move_dest#17 goal was actually created by a plan as a subgoal of the walk_around#1_12 process goal.

Figure 4.3. Goalview and planview

The debugger panel allows watching the event processing inside an agent. The window is made up of the agenda area, the agenda control area in the middle and the details view at bottom (see Figure 4.4, “The Beliefs Panel of Introspector”.

Figure 4.4. The Beliefs Panel of Introspector

The agenda contains all current action entries of the agent, whereby entries in light-grey denote already processed actions. In addition it can be seen whether entries currently have a valid precondition and thus can subsequently be executed; otherwise they are marked as (invalid). Such invalid actions will not be executed, but just ignored by the execution mechanism. To see some more information about an agenda action you can click on it and inspect its values in the details view. In addition to observing the agent's internal behaviour the tool also allows you to control the agenda execution by performing actions in step mode. If the execution mode is set to step or cycle you can use the forward button to execute as many steps as shown in the execute <n> agenda actions choice. The difference between step and cycle mode concerns only the execution of ProcessEventActions that are decomposed to finer-grained sub steps (FindApplicableCandidatesAction, SelectCandidatesAction and ScheduleCandidatesAction) when the step mode is activated. Therefore, the step mode allows you to examine the details of the BDI plan selection process what can be helpful in understanding and explaining unexpected application behaviour. The open steps status bar shows the progress of the action execution by highlighting the number of steps the agent still has to perform whereas in the the processing state line it can be seen if a step is currently requested or has been finished.

The send tab will always be present and allows to compose a new message for sending. The message format follows the FIPA standards (see http://www.fipa.org). You can choose an appropriate performative for your message by using the drop down list of available performatives. The sender is by default initialized with the name of the control center agent. The receivers specify which agents will receive the message. If answers to the message should not be sent to the original sender (default) you can provide an optional reply-to agent. The agent identifiers for sender, receivers, and reply-to are selected using a separate dialog, which can be accessed by clicking the "..." button besides the text field. To clear the agent identifiers click on the "x" button to the right of the "..." button.

The other attributes of the message can be entered as plain strings. For the protocol you can also select one of the protocol types predefined by FIPA. Normally, only a few slots need to be filled in for a message. See e.g. Figure 5.1, “Conversation center overview”, which shows a message commonly used in the [Jadex Tutorial]. After composing the message it can be sent simply by hitting the "Send" button. If it was successfully sent, a copy of the message will be placed in the sent messages list.

You can later reopen the message in a new tab by double-clicking it in the list. To resend the message without changes click the "Send again" button in the newly opened tab. If you wish to change the message before resending it use the "Edit" button instead, which will fill in the slots of the message in the send tab, so you can edit it.

5.1.1. Agent Selector Dialog

The left list of the agent selector dialog (see Figure 5.2, “Agent selector dialog”) shows the agents currently running on the platform. You can double-click on an agent from the list to select it. The upper list on the right side shows the currently selected agent(s). The buttons below the list allow to add a new agent identifier from scratch, which can be edited below the list. When you finished selecting agents, hit the "Ok" (or "Cancel") button at the bottom of the dialog.

Figure 5.2. Agent selector dialog

The messages received by the conversation center agent are placed in the received messages list. Double-clicking on a received message will open it as a new tab (see Figure 5.3, “A received message”). When you want to reply to the message, click on the "Reply" button. The user interface will switch to the send panel, and fill in all slots (receiver, conversation-id, etc.) based on the received message. You can then edit the reply message and hit the "Send" button. If you want to get rid of the tab of a received message, you can use the "Close" button next to the "Reply" button.

Figure 5.3. A received message

The main window of the tracer agent may be seen in Figure 6.1, “Tracer Main Window”. The traces presented here are from the Blocksworld example. In order to indicate a type of traces, they are marked with icons and their different meaning is explained in Table 6.1, “Information logged by the tracer”. The tracer perspective is split into three views including a tree view of agents and traces, a tabular view of traces and a 2D trace space exploring panel.

Figure 6.1. Tracer Main Window

6.1.1. Trace Tree

At the left there is a tree view showing all Jadex BDI agents known to the tracer. The meaning of a particular icon depicting an agent is shown in Table 6.2, “State of an agent”. Descending from the BDI agents, all traces are linked beneath nodes identified to be their cause.

Table 6.2. State of an agent

	The agent did not send any traces yet.
	The agent sends its traces to the tracer.
	The agent is ignored by the tracer.
	The agent died.

The functionality provided by the tree popup menu is similar to the functionality from the Agent Menu (Section 6.2.1, “Agent Menu”) and concerns the currently selected trace or agent. In the case of an agent the user may choose to observer it and to adjust the trace filter and history limit ( Filter ). The other options allow to show or hide traces in the graph or table. With the last menu item the trace or the agent may be removed from the tracer perspective.

Figure 6.2. Tree Popup Menu

The menu provides access to functions concerning the tracer agent itself and the BDI agents analyzed. Functions corresponding to the tabular view and the 2D graph view are also accessible from here.

6.2.1. Agent Menu

Under this menu (cf. Figure 6.3, “Agent Menu” concerning agents the user has the option to:

• Observe - an agent. This will tell the agent to send its traces to the tracer.

• Observe all - will cause all BDI agents (known to the tracer) to send their data.

• Ignore - an agent. Has the complementary effect to Observe.

• Ignore all - is the reverse of Observe all.

• Ignore at first - causes the tracer to ignore all newly occurring agents.

• Show in graph - tells the tracer to show the traces of an agent in the 2D graph as soon as they arrive.

• Hide from graph - removes all agent traces from the 2D graph.

• Show in table - tells the tracer to show the traces of an agent in the table.

• Hide from table - removes all agent traces from the table.

• Delete - removes the agent and corresponding traces from all views.

• Delete dead agents - removes all dead agents and their traces from all views.

• Filter - shows a filter dialog for the current selected agent.

• Default filter - shows a filter dialog for a prototypical agent all new agents will inherit their properties from.

Figure 6.3. Agent Menu

6.2.2. Table Menu

The Table menu (cf. Figure 6.4, “Table Menu” ) provides functionality concerning the table view. Following options are available to the user:

• Select causes - selects immediate causes of selected traces.

• Select effects - selects the immediate effects.

• Show in graph - shows all selected traces in the 2D graph.

• Hide in graph - hides selected traces from the 2D graph.

• Remove - removes traces from the table.

• Delete - deletes the traces and removes them from all views.

• Scroll - tells if the table should be scrolled, when new traces arrive.

Figure 6.4. Table Menu

6.2.3. Graph Menu

The tracer graph menu is accessible from the main menu and as pop-up in the graph view(cf. Figure 6.5, “Graph Popup Menu” ). It provides access to following functions:

• Show - is used to show actions, beliefs or messages connected to trace nodes already shown in the graph. If a trace is selected, the user may choose to show the causes and effects of that trace.

• Hide - hides actions, beliefs or messages from the graph view. A single trace, its causes or its effects may be removed form the view.

• Expand - will expand the trace by one level of the causes or effects.

• Collapse - will shrink and hide the traces around the selected one.

• Delete - will remove the trace from all views in the tracer.

• Join Beliefs - may be used to collapse all belief access nodes into a single one.

• Join Messages - will join the send and receive events of a message with an edge, therefore establishing connections between agents.

• Labels - this check-box indicates that the traces in the graph should be shown with thier corresponding labels instead of an anonymous icon. The labels ar turcated by length and a selected trace is always shown with its label.

Figure 6.5. Graph Popup Menu

Figure 6.6. Agent Filter Dialog

The filter dialog can be accessed from the Agent Menu or from the agent popup menu (see Figure 6.6, “Agent Filter Dialog” ). There is also a Default filter menu item allowing to set the same values for a prototypic agent used for new agents introduced to the tracer.

It allows the user to customize, what kind of traces are interesting for her. The trace type filter can be used to choose among different kinds of traces. The fillter will pass all traces by kind if the corresponding check box is marked. The limit of trace history below allows to store only a specified number of traces in the tracer and may be set for each agent. Moving the slider to the right-most position implies that no limit will be enforced.

Changes in the dialog are applied immeadiately. The dialog will hide when it looses the focus.

The description of the installation process assumes that you have successfully downloaded and installed Protégé™ 2.1 (or later). The installation of the plugin is simple. Extract the plugin.zip file from the beanynizer distribution into the protege/plugins directory. Make sure to use the “Use folder names” option (or similar) of your zip tool, such that a subdirectory protege/plugins/jadex.tools.beanynizer is automatically created. (You can also create this directory by hand before unzipping. In the end you should have a jadex_beanynizer.jar, a plugin.properties file, and some additional jar files in this directory.) Now you can start Protégé™ as usual. The Help → Plugins menu should contain an entry Jadex Beanynizer. Selecting this entry will just take you to the Jadex homepage. For the usage of the plugin see the next sections.

This section only discusses details of the usage of the Beanynizer plugin. For general information about creating ontologies in Protégé™ please consult the Protégé™ documentation. To create an ontology for use with Jadex, follow these four steps:

Figure 7.1. Protégé™ plugin configuration

The general options for the ontology are available from the code generation panel (see Figure 7.2, “Jadex Beanynizer tab”). The ontology name is the name, that will appear in the ontology slot of an ACL messages. From Java this is available with the ontologyclass.ONTOLOGY_NAME constant. A package can be specified, where the ontology class file should be generated. This package is also the default for other generated classes. The class name is the Javaclass name to be used for the ontology (without package). The output directory is the root directory for the package hierarchy to be generated. You can use relative paths here, which will be expanded relative to the saving-location of the Protégé™ project. When subdirectories for some packages do not exist, they will be created on-the-fly.

Figure 7.2. Jadex Beanynizer tab

The Files to Generate option specifies which kind of Java files should be generated for your ontology classes. Note that this option only represents a default, that can be overridden individually for each ontology class as described in the next section.

The Protégé™ classes panel is extended with extra options concerning the code generation. These extra options are shown below the template slots list (see Figure 7.3, “Protégé™ classes panel”, bottom right). As default, the Protégé™ name of the class is used for the .java file. This can be overridden by specifying an additional Java class name. The interface flag can be set, when not a class but an interface should be generated. In general, this only makes sense for abstract ontology classes.

Figure 7.3. Protégé™ classes panel

The package field allows to specify the package of the Java class, overriding the default package specified in the code generation tab. The Generation Options offer the same options as the Files to Genrate, and influence how many files are generated for each ontology class. E.g., setting the option to Fixed allows to include an already existing class in the ontology. In addition, the field can be left blank to indicate that the ontology default should be used. The superclass field and the additional interfaces list, allow to specify fully qualified class or interface names to use as superclass or additionally implemented interfaces. If no superclass is given, the code generator creates a class hierarchy corresponding to the hierarchy in the ontology. For interfaces, only implements interface, . . . is added to the class, the generator does not (yet) magically fill in any missing method implementations.

The code generator generates fields and getter / setter methods for each slot, thereby respecting settings such as name, type, default value, and cardinality (see Figure 7.4, “Protégé™ Slot Options”). For slots that allow multiple values, also add / remove methods are generated. Supported slot types and their default Java mappings are:

Figure 7.4. Protégé™ Slot Options

The name to use for the generated field can be specified using the attribute name option. The Beanynizer has its own idea of Java coding conventions and tries to create a suitable Java name from the slot name, when no specific attribute name is given. The attribute type allows to change the generated Java type, by specifying a fully qualified class name, or one of the basic types (e.g. long). The names of getter and setter methods are derived from the attribute name (which may also be derived from the slot name). Use the get method and set method options to change the names of the methods to generate. This is especially helpful, when including already existing classes in the ontology. The pure Java ontology supports two other settings for slots: transient and external. For transient slots, the field is generated with the transient keyword. External slots are ignored during code generation (this is useful, if the ontology class extends an existing Java class, which already provides the get/set methods for a given slot).

It is possible (while maybe a bit awkward) to convert other ontologies to be used with the Beanynizer. To convert an existing ontology perform the following steps (note, this process has only been tested with Protégé 2.1 and might not work with 3.0):

Protégé™ is a complex tool in itself, therefore a basic understanding of it is essential before you can effectively use the Beanynizer plugin. The Beanynizer is an early staged recent development based on our specific requirements, and does not try to be a general purpose code generation environment. If you encounter problems or miss some features please drop us a note, such that we can improve the Beanynizer for upcoming releases.

Usages of the Beanynizer can be found in the cleanerworld, marsworld and hunterprey examples (look for an "ontology "package). Also, some Jadex tools use a Beanynizer generated ontology for communication (e.g., logger, introspector, and tracer). Their Protégé™ ontology files can be found in the jadex/onto directory.

The Beanynizer was designed for flexible code generation. The code for the Java classes is based on templates processed with the Velocity template engine. The templates for the Java and Jade generation modes can be found in the src/jadex/tools/beanynizer/genjava and src/jadex/tools/beanynizer/genjade directories. If you want to change the way Beanynizer generates code, you may try to alter these templates to suit your needs. See http://jakarta.apache.org/velocity/ for more information about the Velocity template language.

You can start the Jadexdoc tool from a console via:

Description.  Arguments can be in any order. See processing of Source Files for details on how the Jadexdoc tool determines which source files to process.

Generation Dialog.  It is also possible to start Jadexdoc via user interface. The command to start the user interface generation dialog (see Figure 8.1, “Generate Jadexdoc Dialog”) is:

java jadex.tools.jadexdoc.GenerateDialog

Another possibility to start the dialog is diectly from the Jadex Control Center. You can select an agent (or capability) or a package in the model explorer of the starter perspective. Clicking in the toolbar the "Generate Jadexdoc" will open the dialog in which the generation settings can be specified. After successful generation a browser will be opened and the generated documentation is shown.

Figure 8.1. Generate Jadexdoc Dialog

The dialog offers several settings that can be adjusted before the generation is started via the Ok or Apply buttons. The documentation may take a while so the progress of the generation process is shown in the progress bar above the buttons.

The Jadexdoc tool will generate output originating from four different types of "source" files: Agent and Capability source files, package comment files, overview comment files, and miscellaneous unprocessed files.

Processing of source files.  The Jadexdoc tool processes files that end with ".agent.xml" and ".capability.xml" plus other files described below. If you run the Jadexdoc tool by explicitly passing in individual source filenames, you can determine exactly which ADF files are processed. However, that is not how most developers want to work, as it is simpler to pass in package names.

Package Comment Files.  Each package can have its own documentation comment, contained in its own "source" file, that the Jadexdoc tool will merge into the package summary page that it generates. You typically include in this comment any documentation that applies to the entire package.

To create a package comment file, you must name it package.html and place it in the package directory in the source tree along with the agent description files. The Jadexdoc tool will automatically look for this filename in this location. Notice that the filename is identical for all packages.

The content of the package comment file is one big documentation comment, written in HTML, like all other comments. When writing the comment, you should make the first sentence a summary about the package, and not put a title or any other text between <body> and the first sentence.

When the Jadexdoc tool runs, it will automatically look for this file; if found, the Jadexdoc tool does the following:

Overview Comment File.  Each application or set of packages that you are documenting can have its own overview documentation comment, kept in its own "source" file, that the Jadexdoc tool will merge into the overview page that it generates. You typically include in this comment any documentation that applies to the entire application or set of packages.

To create an overview comment file, you can name the file anything you want, typically overview.html and place it anywhere, typically at the top level of the source tree. The content of the overview comment file is one big documentation comment, written in HTML, like the package comment file described previously. When you run the Jadexdoc tool, you specify the overview comment file name with the -overview option. The file is then processed similar to that of a package comment file.

Miscellaneous Unprocessed Files.  You can also include in your source any miscellaneous files that you want the Jadexdoc tool to copy to the destination directory. These typically includes graphic files, example agent description files, and self-standing HTML files whose content would overwhelm the documentation comment of a normal agent description file.

To include unprocessed files, put them in a directory called doc-files which can be a subdirectory of any package directory that contains source files. You can have one such subdirectory for each package. For example, if you want to include the image of a creature Creature.png in the jadex.examples.hunterprey.creature.CleverPrey agent documentation, you place that file in the jadex/examples/hunterprey/creature/doc-files/ directory. Notice the doc-files directory should not be located at jadex/examples/doc-files/ because examples does not directly contain any source files.

All links to these unprocessed files must be hard-coded, because the Jadexdoc tool does not look at the files, it simply copies the directory and all its contents to the destination. For example, the link in the CleverPrey.agent.xml doc comment might look like:

<!-- The image of the CleverPrey agent: <img src="doc-files/Creature.png"> -->

By default, Jadexdoc uses a standard doclet that generates HTML-formatted documentation. This doclet generates the following kinds of files (where each HTML "page" corresponds to a separate file). Note that Jadexdoc generates files with two types of names: those named after agents/capabilities, and those that are not (such as package-summary.html). Files in the latter group contain hyphens to prevent filename conflicts with those in the former group.

Basic Content Pages. 

Cross-Reference Pages. 

Support Files. 

Commenting the Source Code.  You can include documentation comments in the agent description files, ahead of declarations for any agent, capability, plan, goal, event or expression, etc. You can also create comments for each package and another one for the overview, though their syntax is slightly different. The comments in the agent description files are regular xml-comments consisting of the characters between the characters <!-- that begin the comment and the characters --> that end it. The text in a comment can continue onto multiple lines.

<!--
    This is the typical format of a simple documentation
    comment that spans multiple lines.
-->

<!-- To save space you can also put a comment on one line. -->

Placement of comments.  Documentation comments are recognized only when placed immediately before agent, capability, belief, goal, plan, event or expression declarations. Only one documentation comment per declaration statement is recognized by the Jadexdoc tool.

<!-- This is the comment for the agent 'MyAgent' -->
<agent name="MyAgent" package="jadex.examples.myagents">
    <beliefs>
        <!-- The comment for the belief 'MyBelief' -->
        <belief name="MyBelief" class="Object"/>
    </beliefs>
</agent>		

Comments are written in HTML.  The texts can be written in HTML, in that they should use HTML entities and can use HTML tags. You can use whichever version of HTML your browser supports. The bold HTML tag <b> is shown in the following example.

<!-- This is a <b>documentation</b> comment. -->

First sentence.  The first sentence of each documentation comment should be a summary sentence, containing a concise but complete description of the declared member. This sentence ends at the first period that is followed by a blank, tab, or line terminator. The Jadexdoc tool copies this first sentence to the member summary at the top of the HTML page. For convenience, Jadexdoc strips any html tags from this sentence, when it is displayed in a summary table.

The Jadexdoc tool uses a standard doclet to determine its output. The Jadexdoc tool provides a set of command-line options that can be used with any doclet. These options are described below under the sub-heading Section 8.5.1, “Jadexdoc Options”. The standard doclet provides an additional set of command-line options that are described below under the sub-heading Options Provided by the Standard Doclet. All option names are case-insensitive, though their arguments can be case-sensitive.