Spring Boot ApplicationRunner and CommandLineRunner: parse arguments at startup

Choose the argument shape you need

The fixture starts a non-web Boot context with --batch.size=47 and tenant-west. An ordered ApplicationRunner reads the batch.size option as 47. A later CommandLineRunner reads the raw second argument as tenant-west. The checked event list establishes both the argument shape and runner order for this configuration.

An application runner is not a background worker. It executes in the startup path and blocks completion of SpringApplication.run. Bound critical startup work, validate its inputs and fail clearly if the service cannot operate. The failure case checks what happens when a runner rejects startup.

Do not conflate order with readiness

@Order sorts these runners; it does not promise remote dependencies are healthy or that an orchestrator has withdrawn traffic. Readiness groups and shutdown behavior cover separate platform contracts.

Checked code

@Bean @Order(10)
ApplicationRunner validateBatch() {
    return arguments -> runnerEvents.add(
        "typed:" + arguments.getOptionValues("batch.size").get(0));
}
@Bean @Order(20)
CommandLineRunner inspectRawArguments() {
    return arguments -> runnerEvents.add("raw:" + arguments[1]);
}

Verification boundary

The Maven source kit passes LifecycleAndMvcDispatchContractTest.bootRunnersReceiveTypedAndRawArgumentsInDeclaredOrder on its local Spring Boot 4 and Java 21 fixture.

Cost and ownership

Every runner contributes directly to startup time. This local non-web context checks argument parsing and order; it does not check an HTTP listener, deployment readiness, secret handling or whether a remote service is reachable.

Common Mistakes

• Do not index raw arguments without validating their count.
• Do not perform unbounded remote work in a startup runner.
• Do not treat runner order as a substitute for readiness checks.

Read next

Spring Boot runner failure: reject startup instead of accepting unsafe settings, Spring Boot command-line properties: test the effective value at startup, Spring Boot configuration validation: reject an unusable relay before work starts, Spring Boot readiness health group: withdraw traffic on a required dependency failure.