-
Notifications
You must be signed in to change notification settings - Fork 424
picocli vs JCommander
If you like JCommander you’ll love picocli. Picocli is like JCommander on steroids.
JCommander is a great product and is one of the sources of inspiration for picocli. This page gives a quick overview of the differences between picocli and JCommander. The views below are my views, and as picocli’s author I am biased. I still hope this page is useful for people that are trying to decide which command line parsing library to use.
-
Picocli is designed to avoid becoming an external dependency. Few other command line parser seems to have given this problem much thought.
-
Customizable usage help. Like many command line parsers, JCommander is focused on command line parsing, with a fixed usage help message. To customize the usage help in JCommander, one needs to programmatically build a custom help message using the ParameterDescription objects returned from the
JCommanderobject in your application. By contrast, 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.
-
Autocomplete. Picocli can generate a completion script for Bash and ZSH to autocomplete options and subcommands, for any level of subcommand depth.
-
Annotations API and programmatic API (since picocli v3). JCommander only offers annotations. The programmatic API is useful for dynamic applications where the options are discovered at runtime, useful for building a command-line DSL (domain-specific languages) and allows the use of picocli in JVM languages that don’t work well with annotations.
-
Positional parameters are first-class citizens in picocli: strong typing, arity and self-documented in the usage help message. JCommander only supports a list of Strings for positional parameters.
-
Support for clustered POSIX short options, so you can say
<command> -xvfInputFileas well as<command> -x -v -f=InputFile, JCommander only supports the latter. -
Powerful and intuitive arity model that allows a minimum, maximum and variable number of parameters, e.g,
"1..*","3..5". With JCommander one needs to choose between minimum arity or variable arity, and both are weakly typed - Strings only.
-
Converters can be registered on the
CommandLineobject; no need to implement aIStringConverterFactoryinterface -
Arguments can be broken up by specifying a
splitregular expression; no need to implement aIParameterSplitterinterface -
Strongly typed collections (not only Lists) just work; no need to implement a
IStringConverter<List>interface -
Strongly typed Maps (not only Map<String, String>) just work; no need for a
@DynamicParameterannotation -
No
IParameterValidator(I’m open to be convinced otherwise, but I just didn’t see how picocli interfaces would add more value than applications implementing a custom solution.)
-
Register nested subcommands via annotations or fluent API.
-
Fluent and compact API to minimize boilerplate client code:
RunnableandCallableclasses and @Command-annotated methods can parse the command line and run the business logic in a single line of code. -
Powerful parser tracing.
-
Easy integration with Dependency Injection containers.
-
Many built-in type converters for commonly used types.
-
Works with Java 5 or higher (but is designed to facilitate the use of Java 8 lambdas). JCommander requires Java 8.