Life is Too Short to Parse Command Line Parameters
Recently, DZone MVB Cedric Beust unveiled JCommander, a tool he developed
that takes away the manual labor of command line parsing. Just six days
after posting his announcement
for JCommander 1.0, he's already got an expanded 1.1 version
out. New features include simple internationalization, type
converters, and password parameters.
JCommander is a tiny Java framework that works by taking annotated fields with the descriptions of your options and then parsing command line parameters on its own.
Annotated Fields
Finally, if one of your parameters is a password or a value that you want to keep private, you can declare it as a password type and JCommander will ask you to enter the password into the console so that you will be prompted for it whenever you run your program.
Beust got a couple comments on his post voicing support for JCommander. One noted that args4j does something similar but Beust says, "I'm certainly not claiming that the idea is original, plenty of people have pointed out prior similar frameworks (some dating back to 2005), some that I already knew, others I didn't. I'm just surprised that such an approach hasn't become a standard to parse command line parameters, so I thought I'd gather all the best ideas I've heard so far, write my own framework."
Download JCommander from Maven, GitHub, or JAR file.
JCommander is a tiny Java framework that works by taking annotated fields with the descriptions of your options and then parsing command line parameters on its own.
Annotated Fields
import com.beust.jcommander.Parameter;Telling JCommander to Parse
public class JCommanderTest {
@Parameter
public List<String> parameters = Lists.newArrayList();
@Parameter(names = { "-log", "-verbose" }, description = "Level of verbosity")
public Integer verbose = 1;
@Parameter(names = "-groups", description = "Comma-separated list of group names to be run")
public String groups;
@Parameter(names = "-debug", description = "Debug mode")
public boolean debug = false;
}
JCommanderTest jct = new JCommanderTest();Any type of field can be used to represent your parameters (Sting, Integer, Boolean, etc.). Non-basic types (files, host names, lists, etc.) can be written through type converters, which are new in 1.1. JCommander comes with several common converters out of box. You can write a type converter by implementing this interface:
String[] argv = { "-log", "2", "-groups", "unit", "a", "b", "c" };
new JCommander(jct, argv);
Assert.assertEquals(jct.verbose.intValue(), 2);
public interface IStringConverter<T> {
T convert(String value);
}
Beust shows an example of a converter that turns a string into a FIle:public class FileConverter implements IStringConverter<File> {
@Override
public File convert(String value) {
return new File(value);
}
}
Finally, you just declare your field with the proper type and specify
the converter as an attribute:@Parameter(names = "-file", converter = FileConverter.class)For simple internationalization in 1.1, you can specify the bundle for use on your parameter class with the @ResourceBundle annotation. JCommander will resolve your string with the default locale.
File file;
Finally, if one of your parameters is a password or a value that you want to keep private, you can declare it as a password type and JCommander will ask you to enter the password into the console so that you will be prompted for it whenever you run your program.
Beust got a couple comments on his post voicing support for JCommander. One noted that args4j does something similar but Beust says, "I'm certainly not claiming that the idea is original, plenty of people have pointed out prior similar frameworks (some dating back to 2005), some that I already knew, others I didn't. I'm just surprised that such an approach hasn't become a standard to parse command line parameters, so I thought I'd gather all the best ideas I've heard so far, write my own framework."
Download JCommander from Maven, GitHub, or JAR file.
Tags:
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)




