clair077

After looking at command-line processing in Java with Apache Commons CLI , args4j , jbock , and Commandline in previous posts, I turn attention in this post to using JewelCli to accomplish similar processing of command-line arguments in Java. Several Java command-line processing libraries use annotations to define the command-line options. Three of the four libraries covered in this series of posts so far use annotations and so does JewelCli. JewelCli is unique among the libraries I've covered so far because its annotations are applied on a Java interface rather than on a Java class or class's constructs. The next code listing demonstrates how to use annotations on a Java interface to implement the "definition" stage of command-line parsing with JewelCli. JewelCli "Definition" Implemented with Annotated Interface package examples.dustin.commandline.jewelcli; import com.lexicalscope.jewel.cli.Option; /** * Interface defining JewelCli-friendly command-li...

This fourth part of my series on command-line parsing in Java features Commandline , which is described as "a Java library to parse command line arguments" that "is based on a mapping from the command line arguments onto objects, by using annotations." Like previously covered args4j and jbock , Commandline employs annotations to provide the "definition" of potential command-line options. However, while args4j does this via annotations on class fields and jbock does this via annotations on the constructor and its parameters, Commandline uses annotations on "set" (mutator) methods. In this post, I use a Main class example as in the previous posts on Java-based command-line processing, but in normal situations, I'd typically prefer to have a special class representing command-line arguments. The following code listing demonstrates use of Commandline annotations on "get" methods to implement the "definition" stage of Co...

In the first two posts of this series on command-line parsing in Java , I looked at the Apache Commons CLI and args4j libraries. In this third post in the series, I look at jbock , the self-described "curiously simple CLI parser." UPDATE (16 November 2017) : This post describes using jbock 1.8 / 1.8.1 and the examples in this post are based on that version. The author of jbock has provided changes to these examples that work with newly-released jbock 2.1 and the 2.1-compatible changes are incorporated in the full source code available on GitHub . Version 2.1 of jbock requires Java 8 and supports Java 9 modules. My posts on command-line parsing in Java have used examples based on providing a required file name and an optional verbose flag to the Java application. The same approach is used in this post to demonstrate jbock 1.8 . The full source code for the example class is available on GitHub , but the code generated by jbock ( Main_Parser ) is not available as it can ...

In my previous post , I looked at parsing command-line arguments in Java applications using Apache Commons CLI . In this post, I look at doing the same using a different library: args4j . args4j takes a different approach to specifying which command-line arguments the Java application should expect than that used by Commons CLI. While Commons CLI expects objects representing the options to be individually and explicitly instantiated, args4j uses custom annotations to facilitate this "definition" stage of command-line arguments processing. Command-line options are expected to be instance-level fields on the class and are annotated with the @org.kohsuke.args4j.Option annotation. The characteristics of each command-line argument are included as attributes of this @Option annotation. The simple application demonstrated in this post is similar to that used in my previous post and focuses on an optional and valueless -v option for specifying verbosity and a required -f optio...

Although I typically use Groovy to write JVM-hosted scripts to be run from the command-line, there are times when I need to parse command-line parameters in Java applications and there is a plethora of libraries available for Java developers to use to parse command-line parameters. In this post, I look at one of the best known of these Java command line parsing libraries: Apache Commons CLI . I have blogged on Apache Commons CLI before , but that post is over eight years old and describes Apache Commons CLI 1.1 . Two classes that I demonstrated in that post, GnuParser and PosixParser , have since been deprecated. The examples in this current post are based on Apache Commons CLI 1.4 and use the newer DefaultParser that was introduced with CLI 1.3 to replace GnuParser and PosixParser . The Apache Commons CLI documentation's " Introduction " explains how Commons CLI accomplishes the "three stages [of] command line processing" ("definition", "...

I like to use the command-line tools provided with the JDK in the early steps of analyzing performance and other issues with Java-based applications and have blogged on tools such as jcmd , jps , jstat , jinfo , jhat and jmap , jrunscript , jstack , and jdeps . JDK 9 is bringing new command-line tools with multiple tools specifically related to new JDK 9 features such as modularity ( jlink and jmod ) and enhanced deprecation ( jdeprscan ). In this post, I focus on a new command-line tool delivered with JDK 9 for dealing with performance and serviceability issues: jhsdb . The jhsdb tool is described on its Oracle JDK 9 Documentation Early Access page, "You use the jhsdb tool to attach to a Java process or to launch a postmortem debugger to analyze the content of a core-dump from a crashed Java Virtual Machine (JVM)." The tool comes with several "modes" and several of these modes correspond in name and function with individual command-line tools available in prev...