Spring Batch 6: a Java batch framework for restartable, chunk-oriented jobs

The problem Spring Batch solves: jobs that survive a crash mid-run

A shell script that reads a file and inserts rows works until it fails at row 800,000 of a million. Then someone has to work out what was already written. Spring Batch exists to make that question answerable. The README describes it as a lightweight batch framework for enterprise systems, built on the same POJO-based development approach as the Spring Framework, and the design that matters is the one where a job's progress is recorded in a repository so a failed run can be restarted rather than repeated.

It is for Java teams already inside the Spring ecosystem who process data in bulk on a schedule: nightly settlement files, data migrations, report generation, anything where the input is large and the run is long enough that a partial failure is a real possibility. The README's own framing points at daily operations of enterprise systems, and the Apache-2.0 licence keeps it usable in commercial products without a commercial agreement.

The framework is not a scheduler and not a message broker. It decides how a unit of work is read, processed, written, committed and recorded. Something else decides when the job runs.

Chunks, tasklets and the JobRepository: how a Spring Batch job is structured

A Spring Batch job is a named container of one or more steps. The README's two-minute tutorial builds exactly that: a StepBuilder produces one step, a JobBuilder takes that step and calls start, and the resulting Job is launched through a JobOperator. The tutorial's step is a tasklet, a single block of code that returns RepeatStatus.FINISHED when it is done. Tasklets are the escape hatch for work that does not fit a read-process-write shape, such as calling a stored procedure or cleaning a directory.

The other step type is chunk-oriented, and it is the reason most teams pick this framework. The step reads items one at a time, passes each through an item processor, accumulates them, and writes them in a batch when the chunk size is reached, committing the transaction at that boundary. Because the commit boundary and the read position are recorded, a failed job can resume from the last committed chunk rather than from the beginning. The README does not spell out this loop in the tutorial, but the repository layout does: spring-batch-infrastructure holds the item readers, writers and repeat logic, spring-batch-core holds the job, step and repository abstractions, and spring-batch-integration holds the pieces for launching jobs from outside the JVM.

The JobRepository is the load-bearing part. It persists job and step executions, their status and their parameters. That state is what makes restart and skip-and-retry behaviour possible, and it is also the source of the most common operational surprise: a job instance is identified by its name plus its parameters, so launching the same job with the same parameters twice is not a second run, it is a duplicate.

Installing Spring Batch with Maven and running your first job

The README's two-minute tutorial targets Java 17 or later and a Maven project. The only dependency it names is spring-batch-core, pinned in the example to version 6.0.5, which is the release published on 2026-08-21. Add it to your pom.xml:

<dependencies>
    <dependency>
        <groupId>org.springframework.batch</groupId>
        <artifactId>spring-batch-core</artifactId>
        <version>6.0.5</version>
    </dependency>
</dependencies>

The repository also publishes a spring-batch-bom module, which is the usual way to keep the batch artifacts aligned if you pull in more than one, though the README's tutorial does not use it.

Next, declare the job. The tutorial's configuration class is annotated with @Configuration and @EnableBatchProcessing, defines a tasklet step that prints to standard output, and defines a job that starts with that step:

@Configuration
@EnableBatchProcessing
public class HelloWorldJobConfiguration {

    @Bean
    public Step step(JobRepository jobRepository) {
        return new StepBuilder(jobRepository).tasklet((contribution, chunkContext) -> {
            System.out.println("Hello world!");
            return RepeatStatus.FINISHED;
        }).build();
    }

    @Bean
    public Job job(JobRepository jobRepository, Step step) {
        return new JobBuilder(jobRepository)
                .start(step)
                .build();
    }
}

To launch it, the tutorial's main method builds an AnnotationConfigApplicationContext, fetches the JobOperator and the Job from the context, and calls jobOperator.start(job, new JobParameters()). The JobRepository bean is supplied by @EnableBatchProcessing; the tutorial does not configure a DataSource, so the defaults apply. What you should see on the console is the job launched line, the step executing line, the Hello world! output, and a final line reporting the job completed with status COMPLETED.

For something closer to real work, the README points at the Getting Started Guide, Creating a Batch Service, a Spring Boot based ETL example that reads a flat file, transforms it and writes to a relational database. There is also a spring-batch-samples module in the repository with runnable examples.

Where Spring Batch gets in your way

The JobRepository is a database. It needs a schema, and the framework will not create one for you in a production setting; the schema scripts live in the repository rather than in the README, and the tutorial sidesteps the question entirely by not configuring a DataSource. Teams that move from the tutorial to a real deployment hit this first.

The duplicate-instance rule is the second surprise. A job instance is defined by its name and its parameters, so re-running with identical parameters does not start a new instance. The README documents JobParameters in the tutorial but does not discuss this constraint there; it is the kind of behaviour you discover when a rerun silently does nothing. Adding a distinguishing parameter is the usual fix, and the JobParameters type is the place that happens.

Restart is also not free. A job can resume from its last committed chunk, but only if the step is restartable and the reader supports it. A tasklet step that writes 500,000 rows in one transaction has no commit boundary to resume from, so it restarts from zero. Choosing tasklet where chunk would have worked is a common way to lose the framework's main advantage.

Finally, this is a framework for the JVM. If your batch workload is a Python data pipeline or a SQL script inside a warehouse, nothing here helps you, and the JobRepository's schema becomes pure overhead.

Spring Batch vs Spring Boot scheduling, and what people actually compare it to

The comparison the search data keeps returning is Spring Boot against Spring Batch, and it is a category error worth naming. Spring Boot is an application bootstrap and auto-configuration layer. Spring Batch is a batch processing framework. They are not alternatives; the README's own Getting Started Guide is a Spring Boot project that uses Spring Batch. If you want a scheduled method that runs one query, @Scheduled in Spring Boot is the shorter path. If you want a job that reads a million rows, commits every N, records its progress and resumes after a failure, that is Spring Batch's job, and it can still run inside a Spring Boot application.

Against a general-purpose workflow engine such as Apache Airflow, the difference is where the logic lives. Airflow orchestrates tasks written in Python and keeps its state in its own metadata database; the transformation code sits outside the scheduler's process. Spring Batch keeps the transformation logic in the same JVM as the job definition, in typed Java, with the JobRepository holding the execution state in your application's database. That gives you compile-time checking and transactional coupling between the write and the progress record. It costs you the polyglot task model and the cross-system dependency graph an orchestrator provides.

The release cadence is visible in the README's news list: 6.0.0 GA in November 2025, then 6.0.1 through 6.0.5, with 6.1.0-M1 alongside 6.0.5 on 2026-08-21. The last push to the repository was on 2026-09-18. The 5.2.x line received maintenance releases in parallel through June 2026, which matters if you are still on 5 and weighing the migration to 6.

Maintenance, versioning and the licence terms

The repository is not archived and the last push was on 2026-09-18, so the codebase is moving. The release history in the README shows two lines in flight: 6.0.x patches and a 6.1.0 milestone, with 5.2.x still receiving releases as recently as June 2026. The migration from 5 to 6 is a real cost, not a version bump; the major version changed the package structure, which is visible in the tutorial's imports under org.springframework.batch.core.job, org.springframework.batch.core.step and org.springframework.batch.infrastructure.repeat. Code written against Spring Batch 4 or 5 will not compile unchanged against the 6.x imports shown in the README.

Upgrade cost is therefore mostly mechanical but not trivial: find every import of the batch packages, remap it, and re-run your job definitions. The spring-batch-bom module exists to keep the artifact versions aligned once you are on the new line.

The licence is Apache-2.0, which permits commercial and closed-source use and requires that you preserve the licence and attribution notices for the parts you redistribute. That is a summary of the licence identifier, not legal advice; read LICENSE.txt and the Apache-2.0 text before shipping a derivative.

Support moved. The README states that as of January 2026 the project no longer provides support on StackOverflow and directs questions to GitHub Discussions, with the issue tracker reserved for bug reports and feature requests. If your team's habit is to search StackOverflow first, that habit now leads to stale answers.

Editorial conclusion

Adopt Spring Batch when you need restartable, transactional batch processing inside a Spring application: the chunk model, JobRepository state and JobOperator give you a job that resumes rather than restarts. Do not adopt it for a single nightly task that reads one file and writes one table, because Spring Boot's @Scheduled plus a JDBC batch insert carries far less machinery. Before committing, verify that your chosen version's artifact coordinates match what your build resolves, that your database has the JobRepository schema created, and that the migration notes for 5 to 6 cover the APIs your code touches. Note that support requests now go to GitHub Discussions, not StackOverflow, since January 2026.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. spring-projects/spring-batch on GitHub