| Content of these pages are owned and copyrighted by the poster. | |
| Hosted by: |
|
DownloadUtilities; ApplicationsRequirements
Article contributed by GilbertHerschberger (18 December 2000).
Guidelines for utilities are different than the guidelines for applications (ApplicationsRequirements), and should be.
Like all Java programs, a utility should be organized as suggested by ModelViewController . A model should be re-useable in an application, utility and servlet.
Unlike an application, a utility should be AWT-based for maximum compatibility. A utility need not be based on Swing because the AWT for UltimateJOS will be Swing. In other words, your AWT program will eventually look and feel just like Swing anyway when it runs on JOS. Utilities should look and feel like non-Java applications when running on a foreign operating system.
A utility should provide all of the following:
A Java-ready API/framework enables other programmers to embed a utility in their Java applications. If possible, much of the JavaBean model should be relevant.
The Subprogram API provides a straight-forward mechanism to provide a command line API for a utility. Any utility can invoke any other utility through a common Subprogram API.
A utility should be invoke-able from a fill-in-the-blank form. This enables a person to run a utility without looking up information on an API/framework or command line. If possible, a GUI should invoke the utility through a command line interface, not its Java-ready API/framework.
The interactive configuration of the operating system itself and most daemons should be produced as simply as possible, especially now. For example, a utility should be available on all operating systems, regardless of whether they have Swing or not. Swing is not yet available for a few operating systems. A utility based on Swing cannot run on these systems because it is not yet available.
| Content of these pages are owned and copyrighted by the poster. | |
| Hosted by: |
|