Quick truth meter

If you want a tiny Java program that wakes up, does work, then goes back to sleep without serving web pages or pretending to be a REST hero, Spring Boot makes that delightfully boring. This guide shows how to build a console focused Spring Boot application that runs startup logic with CommandLineRunner handles command line arguments and packages as an executable jar for CI or distribution.

Create the project

Use start.spring.io or your favorite IDE to generate a new Spring Boot project. Pick Java and a recent Spring Boot version. Do not add any web server starters if you only want a CLI app. Maven and Gradle both work fine so pick the one you like to yell at in the morning.

Add a CommandLineRunner implementation

CommandLineRunner is the Spring hook that executes after the application context is ready. You can implement it on your main application class or declare a separate @Bean. Put your startup tasks in the run method and Spring will call it once everything else has settled in.

Why use CommandLineRunner

• Runs after Spring is fully initialized
• Perfect for batch jobs initializers and short lived CLI tools
• Integrates with Spring features like dependency injection configuration and lifecycle

Parsing command line arguments

For tiny scripts just inspect the args array plain and simple. For anything more than a flag or two get a real parser. picocli is a popular choice because it gives you nice help output typed options and subcommands without making your life miserable.

When to reach for picocli

• When you need flags options defaults or help text
• When you want subcommands like git style tooling
• When you plan to reuse the CLI across CI scripts or local tools

Run and test locally

From your IDE run the main method. From the command line you can run the app with the JVM or use the Maven or Gradle helper. Pass arguments to exercise flags and verify your startup tasks run as expected.

Typical commands to try are mvn spring-boot:run or java -jar target your app jar Remember to pass arguments after the run command to observe behavior at runtime.

Package for distribution

Build an executable jar with Maven or Gradle so the artifact can be handed off to CI shared drives or other developers. A runnable jar keeps the app self contained and ideal for cron jobs containers or one off scripts.

Example minimal class

@SpringBootApplication
public class App implements CommandLineRunner {
  public static void main(String[] args) {
    SpringApplication.run(App.class, args)
  }

  @Override
  public void run(String... args) throws Exception {
    System.out.println("Hello from CommandLineRunner")
    // Inspect args and do startup work here
  }
}

Yes that is the tiny heart of a Spring Boot CLI tool. Wire services with @Autowired or constructor injection and put the orchestration logic inside run. If you need to return a specific exit code throw an ExitCodeExceptionMapper or call SpringApplication.exit with an ExitCodeGenerator.

Using picocli for nicer UX

Add the picocli dependency and annotate a command class with @Command then delegate parsing to picocli from your CommandLineRunner. This gives you built in help usage messages and typed options so users stop inventing weird flags.

Sketch of a picocli flow

• Define a command class with picocli annotations for options and parameters
• From run delegate to CommandLine to parse and execute
• Let picocli handle generating help and validation

Summary and final snark

Spring Boot is not just for web apps. CommandLineRunner is a neat hook to run startup tasks and build real CLI tools using familiar Spring dependency injection. For trivial needs use the args array for everything else pick a parser like picocli and package into an executable jar with Maven or Gradle. Now go write that one off tool that saves you five minutes each week and gives you enough smug satisfaction to survive another sprint.