Browse Prior Art Database

(JavaDoc EXT) Enhanced JRE to Provide Collaborative JavaDoc Examples Disclosure Number: IPCOM000144863D
Original Publication Date: 2007-Jan-09
Included in the Prior Art Database: 2007-Jan-09
Document File: 3 page(s) / 97K

Publishing Venue



The main idea of Web 2.0 is the use of collaboration, and in the world of programming, collaboration is one of the keys to success. It would make sense to create a means of collaborating through JavaDoc*, and creating the necessary markup tags to accomplish this.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 54% of the total text.

Page 1 of 3

(JavaDoc EXT) Enhanced JRE to Provide Collaborative JavaDoc Examples


JavaDoc is a feature of the Java** Programming language that allows users who create API's (Application Programming Interface) to automatically create documentation on the methods/classes that they create. It uses HTML metatags around classes/methods to describe how the JavaDoc should appear. A JavaDoc program then goes through all the code and examines all the HTML metadata to create HTML pages. The JavaDoc contains descriptions from the author of the code about its background, parameters, exceptions, etc.

Problem Being Solved

Despite the power of JavaDoc, it remains a very predictive system for creating documentation. The problem arises because the author of the code often gives the JavaDoc less attention than the code, leaving much of it incomplete or poorly defined, sometimes even writing JavaDoc information before any user has ever tried or worked with the code. The author is often predicting how the general public will use the code. They may or may not be accurate in that prediction, thus affecting the accuracy of the JavaDoc. The disclosed details how the general public can add their real use cases to the predicted use cases.

The examples that the author uses are also predictive in pattern - they predict how a user will use them and create examples of their code in action. Often times these predictions are wrong and/or oversimplified.

Besides being predictive, the JavaDoc is also reactive. The end-user's JavaDoc usually doesn't get updated until another version of the code is released. Even then, the author is dependent on setting up a means of communication with the users of the code to receive feedback from them about what needs to be updated/changed.

What is needed is a means for updating JavaDoc through an automatic collaborative process, so that users of the code can add examples and further enhance the usability of the JavaDoc sites.

This invention adds capability to the JDK's (Java Developer Kit) compiler (the javac program), the javadoc tool (the javadoc program), or another new Java tool (create a new javadocext program) to read and interpret @example tags in source code and then communicate via a web service with publicly available JavaDoc web sites to provide the examples to them to display in the web site. These examples would enhance the usability of the JavaDoc sites by providing multiple other users' examples of how the methods are used and their 'best practices'.

Interpreting @example tags

When source code is compiled by the javac compiler (or the new javadocext tool), it will encounter a JavaDoc markup tag of @example-start. This tag tells the tool that the sourc...