Table of Contents
- Introduction
- What are
CommandLineRunnerandApplicationRunner? - Differences Between the Two
- When to Use Them
- Implementing
CommandLineRunner - Implementing
ApplicationRunner - Use Cases
- Accessing Command-Line Arguments
- Best Practices
- Conclusion
1. Introduction
In Spring Boot, CommandLineRunner and ApplicationRunner are two special interfaces provided to execute code after the Spring application has fully started and the Spring context is initialized. They’re commonly used for tasks like bootstrapping data, logging startup details, or performing any post-initialization operations.
2. What are CommandLineRunner and ApplicationRunner?
Both CommandLineRunner and ApplicationRunner are callback interfaces used to run code at startup. They are executed after the application context is loaded and right before the application becomes fully available.
CommandLineRunner– provides access to rawString[]arguments.ApplicationRunner– provides access toApplicationArguments(parsed arguments).
3. Differences Between the Two
| Feature | CommandLineRunner | ApplicationRunner |
|---|---|---|
| Argument Type | String[] args | ApplicationArguments object |
| Argument Parsing | Manual | Automatically parsed |
| Usage | Simple arguments | Complex or optional args |
4. When to Use Them
- Use
CommandLineRunnerwhen you just need to access raw arguments directly. - Use
ApplicationRunnerwhen you want to leverage Spring’s parsing capabilities, such as checking for optional or named parameters.
5. Implementing CommandLineRunner
You can create a bean that implements CommandLineRunner:
import org.springframework.boot.CommandLineRunner;
import org.springframework.stereotype.Component;
@Component
public class MyCommandLineRunner implements CommandLineRunner {
@Override
public void run(String... args) {
System.out.println("Application started with CommandLineRunner");
for (String arg : args) {
System.out.println("Arg: " + arg);
}
}
}
Output Example:
java -jar app.jar --spring.profiles.active=dev --customArg=test
This will print each argument in the console.
6. Implementing ApplicationRunner
Here’s how you use ApplicationRunner:
import org.springframework.boot.ApplicationArguments;
import org.springframework.boot.ApplicationRunner;
import org.springframework.stereotype.Component;
@Component
public class MyApplicationRunner implements ApplicationRunner {
@Override
public void run(ApplicationArguments args) {
System.out.println("Application started with ApplicationRunner");
if (args.containsOption("customArg")) {
System.out.println("customArg value: " + args.getOptionValues("customArg"));
}
for (String nonOptionArg : args.getNonOptionArgs()) {
System.out.println("Non-option argument: " + nonOptionArg);
}
}
}
This approach is helpful when you want to handle key-value arguments with more granularity.
7. Use Cases
- Initializing sample data into the database
- Setting up caches
- Printing application startup information
- Triggering some API calls after the application is ready
- Loading configuration or secrets from external sources
8. Accessing Command-Line Arguments
You can access arguments passed to the application in both cases:
java -jar myapp.jar arg1 --custom=value
In CommandLineRunner, args will contain both arg1 and --custom=value.
In ApplicationRunner, args.getOptionNames() will include "custom", and you can retrieve the value using args.getOptionValues("custom").
9. Best Practices
- Use
@Orderor implementOrderedinterface if multiple runners are present and order matters. - Avoid using runners for application logic that should be part of regular services.
- Runners are best suited for dev/test setup, logging, or conditional bootstrapping.
- Wrap critical logic with proper error handling to avoid startup failures.
10. Conclusion
CommandLineRunner and ApplicationRunner provide a clean and simple way to execute code at startup in Spring Boot applications. Choosing the right one depends on the type of arguments and control you need. Understanding and using them effectively can help automate bootstrapping processes, verify configurations, or trigger initial business logic right after the application starts.