Tim On Computer Science

Every once in a while, at the beginning of a new project, I start the search for a command-line argument parsing library in Java. This post shows the results of examining the field as of mid 2018. This post serves both as a “which to use” and as a “which have been evaluated, and found wanting” guide.

* Best So Far
JCommander v1.71
http://jcommander.org/
annotation, good documentation, custom parser, validation

* Honorable Mention
picocli v3.3
http://picocli.info/
annotation, good documentation — documentation looks suspiciously like it is patterned after JCommander

* Pretty Good
args4j
http://args4j.kohsuke.org/
field-based, annotation-based, unclear if “–long-Name” is supported

JewelCLI
http://jewelcli.lexicalscope.com/
annotation-based, interface-based but can be instance-based with setters, has short and long names

* Also-Rans

jopt-simple
https://pholser.github.io/jopt-simple/
Key-Value – the opposite of a good library. Many of the libraries below share this same deficiency.

JArgs
http://jargs.sourceforge.net/
single “parse” call with array of options, Key-Value get value where key is the option

Jakarta Commons CLI
http://commons.apache.org/proper/commons-cli/
like JArgs, except key is “String”, not option object

argparser
http://www.cs.ubc.ca/~lloyd/java/argparser.html
create individual options, where options are “holders”, parse() into the holders

JSAP
http://www.martiansoftware.com/jsap/
old (2008), not well documented

JCommando
http://jcommando.sourceforge.net/
it generates .java, but still requires an additional .jar

Want to see how you can quickly tell that somebody wrote 79,695 lines of Java on a completely wasted library/framework? Watch how quickly JRebirth comes to a head-slap fail:

1) Visit http://www.jrebirth.org/
2) Under Documentation, click on Installation, create the build.gradle
3) Under Documentation, click on “Create your first Application”
4) Create .java for SampleApplication – find out it depends on SampleModel. Ok, then
5) Create .java for SampleModel — find out it depends on SampleView

Hard fail.

A model that has a compile-dependency on the view? “You keep using that word. I do not think it means what you think it means.” Dig a bit further into the source code, and you see the phrase “the class type of the view managed by this model” over and over. The model managing the view?

A model never depends on a view in order to compile, for one simple reason: a correctly designed model can support multiple views simultaneously.

There is no reason to investigate JRebirth further – their project went off the rails at step one.

2018 resolution: Say RIP to REST – aka “the year of RIP REST”

The specific resolution – only use “REST” casually, as a synonym for “client-server”

REST has had a pretty good run. The PhD dissertation was published in 2000. It did an awesome job describing the architecture of the web. Then some one, and then many ones, decided “the web” was a synonym for “enterprise network API”. That was a sad day, and the troubles began. Now, over a decade later, there is finally growing realization that “REST” is a terrible architecture for anything except web pages and maybe some key-value NoSQL APIs.

Section 5.1.5 “Uniform Interface” is one major failing.
Restricting a network architecture to the CRUD verbs is the opposite of “good network architecture”. This “Key-Value” design has been tried many times in the past. And rejected in almost every case. One domain where it stuck was “the web”. Another major failing in REST (although it is not in the dissertation) is the insistence on using HTTP response status codes at the REST level. This “mixing of levels” is another known anti-pattern (can you imagine writing your REST API using EBADF, EACCESS, EINVAL, etc.? Of course not, because the people who created HTTP understood protocol levels. But REST was attached at the hip to HTTP “for simplicity”).

It will be better days from now on – no more creating deficient network APIs in the name of REST. No more useless debates on versioning or HATEOS, or trying to “fix” REST. No more explaining “REST stands for REST Ein’t Soap, Tada!”. (Because that was all REST really was as a network API framework – REST was not SOAP.)

For those interested in what will replace REST, take a look at one possibility in GraphQL http://graphql.org/ GraphQL might not be the winner. But the winner will look a lot like it.