One of Java's great appeals is that the language provides out-of-the-box GUI development capabilities. Still, a lot of us use Java to write command line tools. Such tools are great to automate batch and offline processes. This article presents a framework that jump-starts the development of such tools.
Command line tools are usually invoked from a shell (e.g., DOS prompt, sh, ksh, etc.) and perform a certain task. The task can be customized based on the command line arguments. For instance:
telnet foo.bar.com
attempts to open a telnet connection to host foo.bar.com. It uses the default telnet port. The next example:
telnet -p 3434 foo.bar.com
attempts a similar connection using port 3434.
Command line tools can be as simple or as complicated as the developer desires. An example of a simple command line tool is the echo command found in most shells. On the other hand, the Java compiler and the Java Virtual Machine (JVM) are complex command line tools.
Java presents the command line arguments in an array of strings. This is already a huge improvement over C and C++, in which the arguments are presented as an array of C strings, i.e., an array of pointers to arrays of characters. Yet it comes short of the developer's desire to get the arguments parsed and ready to use.
Since I published my 1997 C++ command line parsing framework (see Reference), many readers have e-mailed me with requests and suggestions. The top two requests have been for a Java implementation and an improvement to handle arrays of arguments. In this article I present a total rewrite of the framework with improvements for Java programmers.
Using the Framework
Before moving to the implementation I'll demonstrate how to use the framework to write a command line utility. Let's say you want to write a utility called "mycat" - like the UNIX cat - which takes a number of files and concatenates them together into a larger file. A -v option turns verbose output on and off. A -l option allows the insertion of extra empty lines between the files. The command would look like:
&127;mycat [-l ] [-v] file1 file2 ... .
In your Main class you need to add a Token object for each argument. In this example we have three Tokens: the number of lines, the verbosity mode and the input files. In addition, you need to add an ApplicationSettings object. This object is used to contain all the arguments.
The source code for these settings is shown in Listing 1. I first declare the sm_main variable and then the three Token variables: sm_verbose, sm_files, sm_lines. The arguments in the constructor of each token object fully describe the expected usage of the Token:
Is it a switch or an argument?
What is the switch's name (e.g., -v)?
What is its type (integer, string, etc.)?
Can it appear multiple times (e.g., -l, 1, -l, 2)?
Is it a required argument?
If not, when the argument is missing:
1. Is there an environment variable to provide the value?
2. Is there a default value?
A static initializer adds the Token variables to the ApplicationSettings variable. By the time the main() function of your application is reached, the ApplicationSettings object knows everything about the syntax of your command line utility.
Listing 2 shows the main program of my example. The first line after the try statement calls the parseArgs() method of the ApplicationSettings object. The actual command line arguments are passed as an argument to the object. When the syntax is incorrect, a usage message is printed and an exception is thrown. Otherwise, the Token objects are set to contain appropriate values. For instance, when the -v option is present, the sm_verbose object will be set. Later, when its getValue() method is called, it will return true.
In a similar fashion, if two files are passed as arguments, let's say foo.cc and bar.cc, the sm_files Token will be set appropriately. Its getValue(0) method will return foo.cc, its getValue(1) method will return bar.cc.
Now compile the example with your favorite development environment and run the resulting code without passing any arguments. You should get the usage message in Listing 3. But wait a minute: you never wrote code to print usage messages; what's going on here? It's very simple. The framework uses the same code that defines the expected Tokens to generate usage statements. Kiss the ugly, always-out-of-date, static String statements that describe the usage of the utility goodbye.
Now let's run the program again with some decent arguments. Let's say we run it with arguments "-v foo.cc bar.cc". The program prints the arguments correctly. Though we didn't pass any value for the -l switch, the Token returns 0. This is the expected behavior because the default value of the sm_lines Token is indeed 0.
Why Use the Framework?
By now some of the advantages of the framework should be obvious to you. The error-prone while and switch statements that usually parse the arguments have been replaced by a few very readable statements.
These statements:
Document the usage of the command line utility
Encapsulate the settings so they can be used by the rest of the program
Automatically generate usage messages when the user enters incorrect syntax:
1. Missing arguments
2. Unexpected arguments
3. Wrong types of arguments
The stated advantages speed up the original development of any command line utility. They allow the developer to jump to the real code as soon as possible. At the same time, they provide immediate access to the command line settings and usage messages.
Where the framework really shines is in the area where most of a developer's time is spent: software maintenance. If a command line utility is successful, users will ask for changes and improvements. Many of them will translate to more command line options or change the syntax of existing ones. The framework makes adding and modifying options trivial and safe. Compile-time messages will save the developer from runtime embarrassment.
Finally, the framework is extensible. One can define new types of switches that accommodate new data types or anything else a developer desires.
At this point you can go ahead, download the code and start using it in your own applications. The next few sections discuss the design of the framework.
The StringArrayIterator Class
The StringArrayIterator class is a utility class (see Listing 4). It encapsulates an array of strings and a position inside the array. The get() method returns the String at the current position. The moveNext() operation on the array allows the programmer to advance the current position to the next string. The EOF() operation determines when the end of the array has been reached.
The ApplicationSettings object contains a StringArrayIterator object. It gets initialized from the command line arguments.
The Token Class
The Token class, shown in Listing 5, is an abstract class. Each Token object contains a description of an argument or a switch. After a successful parsing it also contains the value or values that were provided for the argument in the command line.
During the parsing phase, the most important methods of the Token class are the parseSwitch() and parseArgument() methods. Both of them take the StringArrayIterator object with the command line arguments as input. If the current command line argument is recognized, three things occur: it's parsed, the pointer of the StringArrayIterator object is moved and a value of true is returned. If it's not recognized, a value of false is returned.
The values that correspond to this switch or argument are stored in a Vector of objects. Subclasses determine their class. For instance, the StringToken subclass will have String objects, and the IntegerToken subclass will contain Integer objects.
While the program is running, the values are accessible using the getValue(int) and getValue() operations.
Token Subclasses
A Token subclass encapsulates arguments of a specific type. For example, there's a StringToken, an IntegerToken, etc. Since most of its methods have a generic implementation, each Token subclass has very few methods to implement.
Listing 6 presents the implementation for the class StringToken. A few more subclasses are provided in the downloaded code. You can extend the framework by implementing more subclasses.
The ApplicationSettings Object
The ApplicationSettings object puts everything I've discussed so far together (see Listing 7). It contains all the Token objects and initiates the parsing algorithm. The user triggers the parsing by calling the parseArgs() method.
The command line arguments are assigned to the StringArrayIterator member of the class. Then, for every command line argument, each Token object is called and asked to parse it as either an option or an argument.
If no Token object can parse the argument, a usage message is printed by iterating through the Tokens and calling their printUsage() and printUsageExtended() methods. Both methods take an OutputStream as an argument. They print their output to this stream.
Pure Java and Impurities
Almost all the code is pure Java. Since pure Java doesn't provide support for environment variables and assertions, I had to use the functions provided in my environment, the Win32 Virtual Machine.
These few lines of code are carefully isolated in the util.java file shown in Listing 8. In a pure Java environment you can comment out three lines of code from this file. You don't get assertions and support for initialization of arguments from environment variables. Otherwise, everything else works as advertised.
Limitations
The framework doesn't provide support for complex scenarios. For instance, there's no support for switches that depend on each other. You can't dictate that the -t option can appear if and only if the -p option appears. You'd have to implement such checks yourself after the arguments were parsed.
Conclusion
In this article I presented an extensible Java framework. The framework simplifies the development and maintenance of code that parses the arguments of command line utilities and tools.
The framework doesn't provide support for complex scenarios. Still, my experience is that the framework covers most common cases. I expect that it will be as useful for Java development as it has been for C++.
Reference
P. Kougiouris (1997). "Yet Another Command-Line Parser." C/C++ Users Journal, Vol. 15, No. 4, April.
Subscribe to JAVA Developer's Journal Email News Alerts
Subscribe via RSS
