Browse Prior Art Database

JavaDoc development environment Disclosure Number: IPCOM000015735D
Original Publication Date: 2002-Mar-06
Included in the Prior Art Database: 2003-Jun-21

Publishing Venue



A cumbersome process in Java development is the authoring of JavaDoc comments, which are comments imbedded in the Java source. It is cumbersome because JavaDoc comments are destined to become HTML comments displayable in a Web browser, but you cannot see them until the "javadoc" tool from the Java Development Kit (JDK) is run against the source files, and the resulting html files are brought up in a Web browser. It is only after these steps that you can see if the result is appealing and properly formatted. Depending on the Java IDE or editor used, the programmer often has to leave the IDE/editor to lauch the JavaDoc tool, and then has to manually launch the Web browser to see the results. Finessing JavaDoc comments can be an iterative and time-consuming task. Further, even reading JavaDoc comments of existing Java code is a process not integrated with the development environment, again as it requires launching a Web browser on the HTML files that are the output of the JavaDoc process. These are typically not at-hand in the Java development environment, which is focused on Java source editing. This idea is to extend any Java development environment to support the development and viewing of JavaDoc comments in an environment that integrates the development of Java source code with the development and display of JavaDoc comments. Modern Java Integrated Development Environments (IDEs), such as the IBM WebSphere Studio Application Developer (WSAD) enable productive development of Java source code by showing a tree-view on the left which lists projects, inside of which are Java packages, inside of which are Java classes and interfaces (these last two are file system artifacts). The developer double clicks on a Java class or interface to open an editor on the right hand side, or right clicks and selects to open the file in the editor. Typically, multiple editor panes can be opened simultaneously and they are arranged in a tabbed view such that selecting a tab brings that editor pane to the foreground. It is within an editor pane the source code editing is done, including the editing and authoring of the JavaDoc comments within the source. This invention would add a new menu item when a class or interface is right clicked, to bring up an imbedded or external Web browser to view the JavaDoc comments for the selected class or interface. If the IDE supports an imbedded Web browser, which shows up as a pane in the IDE versus an external window, then this would be shown within the real estate of the IDE. For example, it might show up as another tab among the editor tabs. If the IDE supports an external Web browser, then it is launched as a separate window. Often, Microsoft Internet Explorer is supported as an imbedded Web browser via its ActiveX control, while Netscape and others are launched. Regardless of where the Web browser is shown, its contents would be the output of the "javadoc" tool from the Java Development Kit on the selected class or interface. The tool would be smart enough to know if the JavaDoc comments in the source code have changed, and if so automatically regenerate the JavaDoc output by re-running the "javadoc" tool prior to launching the Web browser. This could be done in a number of ways. The simplest would be to just regenerate if the source file has changed at all since the last time "javadoc" was run, which could be computed by simply comparing the last-modified date of the .java source file versus the generated .html file. However, this is not very precise as the source may have changed but not the JavaDoc comments in the source. Preferrably, the tool will be able to detect if any JavaDoc comment has changed within the file, and set a property indicating the "javadoc" tool must be re-run. Advanced Java tools can easily detect this as part of their editor parsing or their increment compiling. Typically the "javadoc" tool is not run against an individual file, but rather an entire package or even multiple packages, say within one project. This enables the tool to resolve links between JavaDoc comments in different Java source files. To be really effective, the programmer should be able to specify via a property page or preference page if the "javadoc" regeneration should be against the selected file, or the whole package, or the whole project. Furthermore, to enable fast regeneration at a package or project level, the "javadoc" tool would be enhanced to support incremental generation, so that only the JavaDoc output for those files in the package or project that have changed would be regenerated, or other files