What are JobParameters in Spring Batch, and how do you build them?
answer
- typed key/value launch inputs
- JobParametersBuilder.addString/addLong/addDate
- JobLauncher.run(job, params)
- @Value(#{jobParameters['key']}) in step scope
- immutable, persisted with JobExecution
basics
~10 sJobParameters are typed key/value inputs passed to a job at launch (Strings, Longs, Doubles, Dates). You build them with JobParametersBuilder and pass them to JobLauncher.run(job, params).
solid answer
~40 sJobParameters is an immutable, ordered map of typed key/value pairs supplied to a batch job at launch time — the runtime inputs a job needs (a file path, a run date, an id). Each value carries a concrete type (String, Long, Double, Date, or, in newer versions, any type via a converter), so you don't parse raw strings yourself. You assemble them with JobParametersBuilder (addString, addLong, addDate, addLocalDate…), then pass the built JobParameters to JobLauncher.run(job, jobParameters). Spring Batch persists them with the JobExecution in the metadata tables, and you can inject individual values into steps/beans with @Value("#{jobParameters['key']}") in step scope. They also help define which JobInstance a run belongs to.
code
java · 18 linesJobParameters params = new JobParametersBuilder()
.addString("inputFile", "orders-2026-07.csv")
.addLong("runId", 42L)
.addLocalDate("businessDate", LocalDate.now())
.toJobParameters();
JobExecution execution = jobLauncher.run(ordersJob, params);
// Late-binding a single value inside a step-scoped bean:
@StepScope
@Bean
public FlatFileItemReader<Order> reader(
@Value("#{jobParameters['inputFile']}") String inputFile) {
return new FlatFileItemReaderBuilder<Order>()
.name("orderReader")
.resource(new FileSystemResource(inputFile))
.build();
}go deeper
Know they are typed launch inputs built with JobParametersBuilder and passed to JobLauncher.run.
Add late-binding via @Value SpEL and why step scope is needed.
Connect parameters to persistence in metadata tables and JobInstance identity.
Discuss the Spring Batch 5 JobParameter<T> generalization and converter strategy.
## What JobParameters are `JobParameters` (class `org.springframework.batch.core.JobParameters`) is an **immutable, typed key/value collection** passed into a Spring Batch job when it is launched. Think of it as the job's command-line arguments: the values that vary from run to run — an input file name, a processing date, a customer id, a `run.id`. Unlike a plain `Map<String,String>`, each entry is a `JobParameter` that knows its **Java type**. Legacy supported types were `String`, `Long`, `Double`, and `Date`; Spring Batch 5+ generalized `JobParameter<T>` so any type can be stored given a converter, and added conveniences like `addLocalDate`. ## Building them You almost never construct `JobParameters` directly. You use the fluent `JobParametersBuilder`: ```java JobParameters params = new JobParametersBuilder() .addString("inputFile", "orders-2026-07.csv") .addLong("runId", 42L) .addLocalDate("businessDate", LocalDate.now()) .toJobParameters(); ``` Then launch: ```java JobExecution exec = jobLauncher.run(ordersJob, params); ``` ## How values reach your code Spring Batch persists the parameters alongside the `JobExecution` in the metadata tables (`BATCH_JOB_EXECUTION_PARAMS`). Inside a **step-scoped** bean you can late-bind a single value: ```java @Value("#{jobParameters['inputFile']}") String inputFile ``` Step/job scope is required because the parameters are only known at launch, after the bean context is built. ## Why typed Typing means the framework stores `businessDate` as a real date, comparison for `JobInstance` identity is type-aware, and you avoid ad-hoc `String` parsing. ## Gotchas - `JobParameters` is **immutable** — build a new one per launch. - Parameters also participate in **JobInstance identity** (see identifying vs non-identifying), which is why re-running with the same parameters can throw `JobInstanceAlreadyCompleteException`. - With Spring Boot's `CommandLineJobRunner`/job launcher, CLI args like `inputFile=foo.csv` are parsed into `JobParameters`.
- Why must a bean using @Value("#{jobParameters[...]}") be step- or job-scoped?Job parameters are only known at launch time, after the application context is already built. Step/job scope defers bean instantiation until the step runs, so SpEL can resolve the parameter for that execution.
- What types can JobParameters hold?Classically String, Long, Double, and Date. Spring Batch 5 generalized JobParameter<T> so any type is supported via a converter, with helpers like addLocalDate.
saying these in an interview costs you the question
- Saying JobParameters is a plain Map<String,String> with no typing
- Claiming you can inject job parameters into a singleton bean without step/job scope
- Thinking JobParameters is mutable