How often have you chosen to write code to parse command line arguments instead of using a library because you didn’t want to burden your users with the extra dependency?
A library can be a great help, but it won’t make your users happy when they get a command line application and in order to run it they need to download and specify another jar file, especially when the only purpose of this library is to make life easier for the application author. It tells people that the author chose to make end users do more work so that the author could do less work. Not nice.
This is one way to solve that problem. It is easy to understand, easy to do, and it doesn’t require any special tooling.
That is another way to solve the problem. It requires some tooling, but it can certainly work. You have somewhat less visibility on what actually goes into the uberjar, and there are some times when shading can cause issues, but that’s usually when more libraries are combined.
However, including the source is simpler and avoids these issues.
Good point. There is always a trade-off. In this case, the trade-off is that it makes my work as a maintainer slightly harder, but makes things easier for the end user. That’s a good trade-off in my book.
Under the hood there are actually quite a few inner classes and interfaces, so it’s not as bad as you would think. The IDE does a good job here. We’ll see if it becomes a problem down the road, but if it does, it’ll be my problem and not the end user’s.
JCommander is a great product and is one of the sources of inspiration for picocli.
-
Strongly typed positional parameters (in JCommander only options are strongly typed, positional parameters are a list of Strings)
-
Support for POSIX short options (so you can say
<command> -xvfInputFileas well as<command> -x -v -f=InputFile, JCommander only supports the latter) -
An arity model that allows a minimum, maximum and variable number of parameters, e.g,
"1..*","3..5"(JCommander only has minimum or variable arity, and these are weakly typed - Strings only) -
Fluent and compact API to minimize boilerplate client code.
-
Works with Java 5 or higher (but is designed to facilitate the use of Java 8 lambdas). JCommander requires Java 8.
-
Picocli is designed to avoid becoming an external dependency. No other command line parser seems to have given this problem much thought.
-
Customizable usage help. People have requested customizable help in JCommander for years but it’s not happening. Picocli provides annotations to easily customize common aspects of the usage help message. If the annotations are not sufficient, picocli provides a Help API for uncommon customizations.
-
Ansi colors and styles. Picocli usage help uses unobtrusive and easily customizable colors and styles where supported. Ships with a simple markup notation to allow application authors to colorize custom usage messages like headers, footers, description, etc.
-
support for suppressing password echo to the console
-
case-insensitive option name matching
-
support for abbreviated options
-
support for Map fields
-
internationalization
Please see the CLI comparison page for a detailed comparison.
