clair077

This series on parsing command line arguments from Java has briefly introduced 28 open source libraries that can be used to process command-line arguments from Java code. Even with these 28 libraries covered, the series has not covered all available open source libraries for parsing command line options from Java. For example, this series has not covered docopt , dolphin getopt , DPML CLI , the "other" JArgP , java-getopt , ritopt , cli-args , clio , TE-CODE Command , and likely many other libraries I'm not aware of. This post looks at considerations one might make when attempting to decide whether to roll one's own command line argument parsing code in Java versus using one of the plethora of command line parsing libraries that is already available. At first glance, it would be easy to say that someone developer their own command-line parsing code in Java might be suffering from Not Invented Here Syndrome . However, I still occasionally write my own simple command ...

The page for getopt4j describes this as "a library to parse command line arguments according to the GNU style." The page then introduces getopt4j : "The 'getopt4j' library is designed to parse the command line options in the same manner as the C getopt() function in glibc (the GNU C runtime library). It attempts to do this in a simpler, more Java-centric manner than the original product." This post describes use of getopt4j to parse command line options in the same manner as was done for the libraries covered in the earlier 27 posts in this series . The "definition" stage is accomplished in getopt4j via instances of CLOptionDescriptor as demonstrated in the next code listing (full source code is available on GitHub ). "Definition" Stage with getopt4j final CLOptionDescriptor fileDescriptor = new CLOptionDescriptor("file", CLOptionDescriptor.ARGUMENT_REQUIRED, 'f', "Path and name of file....

CLI Parser , originally hosted on and now archived on Google Code , is now available on GitHub . The archive Google Code project page describes CLI Parser as a "very simple to use, very small dependency" that uses annotations to "make very succinct main methods that don't need to know how to parse command line arguments with either fields, properties, or method based injection." The current GitHub project page describes CLI Parser as "a tiny ..., super easy to use library for parsing various kinds of command line arguments or property lists." CLI Parser expects the "definition" stage to be implemented via the @Argument annotation. This is demonstrated in the next code listing, which provides a simple example defining "file" and "verbose" options as has been done in previous posts in this series . The complete code listing is available on GitHub . "Definition" Stage with CLI Parser @Argument(alias="f...

I became aware of the twenty-sixth featured Java-based library in this series on parsing command line arguments because of a Tweet . CmdOption is described on its main GitHub page as "a simple annotation-driven command line parser toolkit for Java 5+ applications that is configured through annotations." The project's subtitle is, "Command line parsing has never been easier." The annotation @CmdOption is used to annotate fields (or methods) that will contain the parsed command-line arguments. In other words, it is with the @CmdOption annotation that the "definition" stage is accomplished with CmdOption. This is shown in the next code listing. "Definition" Stage with CmdOption @CmdOption(names={"--file","-f"}, description="File Path/Name", minCount=1, args={"filePathAndName"}) private String file; @CmdOption(names={"--verbose","-v"}, description="Is verbosity enabled?"...

JCommando is described on the JCommando site as "a Java argument parser for command-line parameters." JCommando reads XML configuration to generate a Java class that handles parsing from a Java application. The only Java-based library previously covered in this series of posts on Java command-line parsing libraries that provided XML configuration is JSAP , but it's a secondary form of configuration with that library and I did not cover XML configuration in my post on JSAP . Because JCommando uses XML to specify command line options to be parsed, the "definition" stage with JCommando is accomplished via XML specification. As with the previous posts in this series , the examples in this post are based on command line options for file path and name and verbosity and their definition in JCommando-compliant XML is shown in the next code listing ( options.xml ). JCommando via XML Portion of "Definition" Stage: options.xml <jcommando> <opti...

The first post in this series on parsing command line arguments in Java featured the Apache Commons CLI library. This is one of the oldest and likely one of the most commonly used of the Java-based command-line parsing libraries covered in this series . Apache Commons CLI does show its age, especially when contrasted with some of the more modern Java-based command-line processing libraries. Mark A. Ziesemer 's "CLI library wrapper on Apache Commons CLI," called MarkUtils-CLI, was designed to "modernize" Apache Commons CLI and is the subject of this blog post. In the blog post " MarkUtils-CLI: Annotations (and more) for Apache Commons CLI ," Ziesemer writes: I feel that the Apache Commons CLI project is selling themselves short. I've found it to be a very comprehensive, well-designed library for effectively parsing the command-line. The only shortcoming I've observed is that the project was developed before Java 5 - and annotations - were a...

The Rop library is described on its main page as "a lightweight command line option parser written in Java." The "Introduction" to Rop also states, "Rop is designed to be minimal meanwhile convenient, and to cover most usual command line parsing use cases." This post is the twenty-third in this series on parsing command line arguments in Java and focuses on Rop. Like the twenty-two posts in this series before this one, this post uses examples implementing two command line options, one for file path and name and one for verbosity level. The full code listing the example is available on GitHub . The "definition" stage is accomplished in Rop via annotations @Command and @Option (both of which are nested within class com.github.ryenus.rop.OptionParser ). This is shown in the next code listing. "Definition" Stage with Rop /** * Demonstrates use of Rop for processing command line * parameters in Java. */ @Command(name="RopDemo...

John Lloyd 's argparser is the library covered in this twenty-second post of the series on Java-based command line argument parsing. The main page for the library provides links to Javadoc-based API documentation , a JAR file, a ZIP file, and a TAR file in addition to a single source code example. The example used in this post is similar to the examples used in the first twenty-one posts in this series and processes file path/name and verbosity options. The full code listing is available on GitHub . The "definition" stage is accomplished in argparser with instances of "Holder" classes representing the expected options that are passed to the addOption(String,Object) method of an ArgParser instance. This is demonstrated in the next code listing. "Definition" Stage with argparser final StringHolder file = new StringHolder(); final BooleanHolder verbose = new BooleanHolder(); final ArgParser parser = new ArgParser("java examples.dustin.commandli...

The focus of this twenty-first post in this series on parsing command-line arguments in Java is on the Airline 2 library. The GitHub project page for Airline 2 describes the library, "Airline is a Java library providing an annotation-based framework for parsing command line interfaces." The page goes onto state that Airline "supports both simple single commands through to complex git style interfaces with groups." The page also defines Airline 2's relationship with the original Airline library : "This is a substantially rewritten fork of the original airline library ." It is specifically Airline 2.3.0 that is featured in this post. The examples in this post will be similar to those demonstrated in earlier posts in this series on alternative libraries for parsing command line arguments from Java. As such, the options supported in these examples will be specification of a file's path and name and specification of whether or not verbosity should b...

JSAP ( Java Simple Argument Parser ) 2.1 is the focus of this twentieth post in this series on processing command line arguments from Java. The JSAP page describes the library's reason for existence: "I found several parsers on the Internet, all of which handled switches, but none of which had the versatility I wanted in terms of return types and configuration files." JSAP offers quite a bit of flexibility at the normal cost of some complexity. Fortunately, JSAP provides a class called SimpleJSAP that makes it easier to accomplish simple tasks with JSAP. The JSAP documentation articulates it this way , "If you want to minimize the amount of code handling the command line, JSAP offers a SimpleJSAP that does most of the work for you." The next code listing demonstrates using SimpleJSAP in a single (albeit verbose) statement to define the expected command line options. "Definition" Stage with JSAP final SimpleJSAP jsap = new SimpleJSAP( "Mai...

The focus of this nineteenth post in this series on parsing command line arguments from Java code is jClap ( Java Command Line Argument Parser ), which should not be confused with the library called JCLAP that was the focus of my previous post in this series. The previous post covered JCLAP 1.4 by Giles Winstanley ( snaq.net ) whereas this post covers jClap 2.0 by Jan So ( extreme_logic ). The "definition" stage is implemented jClap by instantiating an instance of com.extremelogic.common.jclap.Argument and invoking one of the overloaded methods with names addArgument or addBooleanArgument . This is demonstrated in the next code listing (full code in available on GitHub ). "Definition" Stage with jClap final Argument argument = new Argument(arguments); argument.addArgument("file", "Path/name of file", true, 1); argument.addBooleanArgument("verbose", "Enables verbosity", false); The previous code listing demonstrates...