DEV Community

Cover image for Native CLI with Picocli and GraalVM

Native CLI with Picocli and GraalVM

jbebar profile image jbebar ・5 min read


Let's imagine a CLI which takes as parameters option a client name and selects a random beer for this person, example:

./beer ---name "Jean-Michel"
Let's see what the barman found....
Hey Jean-Michel, you should try: Strong IPA 
Enter fullscreen mode Exit fullscreen mode

The CLI is written in Kotlin and uses Picocli to generate a standard help menu and to parse command line options. I will not detail Picocli in this post but the build process of an executable.

Why Graal VM?

If we run this CLI using a jar packaging and java command we have two downsides:

  • startup time of the JVM, users will not want to wait to order their beer.
  • ask the user to install a JVM in the right version
  • the command to launch the CLI will look like java -jar name-of-the-cli.jar whereas we would expect a simple command like this name-of-the-cli.

That's where GraalVM can save us here, it can compile directly java byte code down to binaries for a particular machine (Linux in our example):

  • No more JVM to install for our users
  • Almost no startup time
  • A simple command, as we just have to call the executable file from command line.

GraalVM is a polyglot VM to run many languages (Java, Kotlin among many others) in an optimized way. GraalVM can also be used as a JDK if you develop in Java/Kotlin to compile to Java bytecode.

It comes with the native-image tool can be installed on top of GraalVM to build natives executables from java bytecode.
For this purpose, GraalVM needs to anticipate any runtime reflections operations done, for instance, by the Picocli library. This special compilation is called ahead of time. Every annotation used at runtime in our code will need to come with it's configuration file. These configurations files can be done manually, but usually frameworks provides tools to generate them. Fortunately, that's the case for Picocli.

Adapt our configuration to generate GraalVM configuration files:

Our only source file is the following, we won't need to adapt it but let's keep it here for our understanding:


import picocli.CommandLine
import picocli.CommandLine.Command
import picocli.CommandLine.Option
import java.util.concurrent.Callable

    name = "beer",
    mixinStandardHelpOptions = true,
    version = ["beer 0.0.1"],
    description = ["Chooses a random beer for you."]
internal class BeerCallable : Callable<Int> {

    @Option(names = ["-n", "--name"], required = false, description = ["Your name."])
    var name: String = "John Doe"

    override fun call(): Int {
        val beers = listOf("Black IPA Beer", "Light Blond", "Strong IPA", "Red Beer", "White Beer")
        println("Let's see what the barman found....")
        println("Hey $name, you should try: ${beers.shuffled().first()} !")
        return 0

    companion object {
        fun main(args: Array<String>) {
            val exitCode: Int = CommandLine(BeerCallable()).execute(*args)
Enter fullscreen mode Exit fullscreen mode

Our initial build.gradle looks like this:

plugins {
    kotlin("jvm") version "1.3.72"

group = "org.jbebar"
version = "1.0-SNAPSHOT"

repositories {

dependencies {

tasks {
    compileKotlin {
        kotlinOptions.jvmTarget = "1.8"
    compileTestKotlin {
        kotlinOptions.jvmTarget = "1.8"
Enter fullscreen mode Exit fullscreen mode

To use the configuration files generators for picocli library we need to add these lines to our build.gradle.kts :

  • plugins { kotlin("kapt") version "1.3.72" } : this will enable annotation processing for kotlin.
  • dependencies { kapt("info.picocli:picocli-codegen:4.5.0") } : Using annotation processing from kotlin during java compilation, it will scan for picocli annotations and generate the corresponding configuration files for graalVM.
  • kapt { arguments { arg("project", "${}/${}") } } : this will give the jar a unique name and prevent shading from other jars in the case of a uber jar.

After adapting our build.gradle and running gradle clean build we can see the following structure in the generated jar:

Alt Text

If we have a look closer, only one configuration file is filled, the reflect-config.json. It refers to the runtimes annotations used by our code and picocli dependency: the field annotated in their class are detailed in the config.

    "name" : "",
    "allDeclaredConstructors" : true,
    "allPublicConstructors" : true,
    "allDeclaredMethods" : true,
    "allPublicMethods" : true,
    "fields" : [
      { "name" : "name" }
    "name" : "picocli.CommandLine$AutoHelpMixin",
    "allDeclaredConstructors" : true,
    "allPublicConstructors" : true,
    "allDeclaredMethods" : true,
    "allPublicMethods" : true,
    "fields" : [
      { "name" : "helpRequested" },
      { "name" : "versionRequested" }
Enter fullscreen mode Exit fullscreen mode

If we check the rentention policy of these annotations, we see that @Option has RUNTIME retention on our field name of class BeerCallable.

Alt Text

Same for the AutoHelpMixin class.

Alt Text

Install GraalVM

To install GraalVM, I let you refer to the documentation for your platform. GraalVM needs C/C++ compilation tools to build the native-images.

After installing GraalVM you can run:

gu install native-image

Compile to native code

Before compiling to native code, it is good to check our application is running using java command, gathering all the dependencies and the source jar in the same folder and use the --classpath or -cp option like this:

java -cp annotations-13.0.jar:kotlin-stdlib-1.3.72.jar:kotlin-stdlib-common-1.3.72.jar:kotlin-stdlib-jdk7-1.3.72.jar:kotlin-stdlib-jdk8-1.3.72.jar:picocli-4.5.0.jar:beer-picocli-1.0-SNAPSHOT.jar
Enter fullscreen mode Exit fullscreen mode

Be careful about putting the source file containing the Main class as last dependency in the list passed to -cp. The only argument to pass on top of the option is the name of the class containing the main method.

This will give the following output:

Let's see what the barman found....
Hey John Doe, you should try: Red Beer !
Enter fullscreen mode Exit fullscreen mode

Now, to compile we can stay in the same folder containing our dependencies and CLI jar and run:

native-image -cp annotations-13.0.jar:kotlin-stdlib-1.3.72.jar:kotlin-stdlib-common-1.3.72.jar:kotlin-stdlib-jdk7-1.3.72.jar:kotlin-stdlib-jdk8-1.3.72.jar:picocli-4.5.0.jar:beer-picocli-1.0-SNAPSHOT.jar -H:Name=beer

where -H:Name=beer is the name of the generated executable.


./beer -h
Usage: beer [-hV] [-n=<name>]
Chooses a random beer for you.
  -h, --help          Show this help message and exit.
  -n, --name=<name>   Your name.
  -V, --version       Print version information and exit.
./beer -n "Jean-Michel"
Let's see what the barman found....
Hey Jean-Michel, you should try: Strong IPA !
Enter fullscreen mode Exit fullscreen mode

We can also compare the execution times :

time java -cp annotations-13.0.jar:kotlin-stdlib-1.3.72.jar:kotlin-stdlib-common-1.3.72.jar:kotlin-stdlib-jdk7-1.3.72.jar:kotlin-stdlib-jdk8-1.3.72.jar:picocli-4.5.0.jar:beer-picocli-1.0-SNAPSHOT.jar
Let's see what the barman found....
Hey John Doe, you should try: Black IPA Beer !

real    0m0.316s
user    0m0.473s
sys 0m0.060s
Enter fullscreen mode Exit fullscreen mode

With graal VM we can see that the real time is nearly 8 times faster.

time ./beer
Let's see what the barman found....
Hey John Doe, you should try: Black IPA Beer !

real    0m0.044s
user    0m0.006s
sys 0m0.005s

Enter fullscreen mode Exit fullscreen mode

Don't take this "8 times" for granted, of course, it will depend on the type of program you run. But this gives a good idea of how fast it is. The user will not see the difference between this or any system command run from terminal, and that's kind of magical.

To see even more the difference, it could be interesting to run this with programs manipulating larger sets of data.
I hope now our client will not wait to know which beer to drink and take it right out of the fridge.
More seriously, would you now try GraalVM and Picocli combination? Or do you have any other way of writing your CLI apps? Feel free to comment :) and see you soon.

Discussion (0)

Editor guide