This section shows the major highlights of Spring Batch 5 and is not an exhaustive list of changes. For more details, please refer to the migration guide.

What’s New in Spring Batch 5.0

Spring Batch 5.0 has the following major themes:

  • Java 17 Requirement

  • Dependencies Re-baseline

  • Batch infrastructure configuration updates

  • Batch testing configuration updates

  • New features

  • Pruning

Java 17 Requirement

Spring Batch follows Spring Framework’s baselines for both Java version and third party dependencies. With Spring Batch 5, the Spring Framework version is being upgraded to Spring Framework 6, which requires Java 17. As a result, the Java version requirement for Spring Batch is also increasing to Java 17.

Dependencies Re-baseline

To continue the integration with supported versions of the third party libraries that Spring Batch uses, Spring Batch 5 is updating the dependencies across the board to the following versions:

  • Spring Framework 6

  • Spring Integration 6

  • Spring Data 3

  • Spring AMQP 3

  • Spring for Apache Kafka 3

  • Micrometer 1.10

This release also marks the migration to:

  • Jakarta EE 9

  • Hibernate 6

Batch Infrastructure Configuration Updates

Spring Batch 5 includes the following infrastructure configuration updates:

Data Source and Transaction manager Requirement Updates

Historically, Spring Batch provided a map-based job repository and job explorer implementations to work with an in-memory job repository. These implementations were deprecated in version 4 and completely removed in version 5. The recommended replacement is to use the JDBC-based implementations with an embedded database, such as H2, HSQL, and others.

In this release, the @EnableBatchProcessing annotation configures a JDBC-based JobRepository, which requires a DataSource and PlatformTransactionManager beans to be defined in the application context. The DataSource bean could refer to an embedded database to work with an in-memory job repository.

Transaction Manager Bean Exposure

Until version 4.3, the @EnableBatchProcessing annotation exposed a transaction manager bean in the application context. While this was convenient in many cases, the unconditional exposure of a transaction manager could interfere with a user-defined transaction manager. In this release, @EnableBatchProcessing no longer exposes a transaction manager bean in the application context.

New annotation attributes in EnableBatchProcessing

In this release, the @EnableBatchProcessing annotation provides new attributes to specify which components and parameters should be used to configure the Batch infrastructure beans. For example, it is now possible to specify which data source and transaction manager Spring Batch should configure in the job repository as follows:

@Configuration
@EnableBatchProcessing(dataSourceRef = "batchDataSource", transactionManagerRef = "batchTransactionManager")
public class MyJobConfiguration {

	@Bean
	public Job job(JobRepository jobRepository) {
		return new JobBuilder("myJob", jobRepository)
				//define job flow as needed
				.build();
	}

}

In this example, batchDataSource and batchTransactionManager refer to beans in the application context, and which will be used to configure the job repository and job explorer. There is no need to define a custom BatchConfiguer anymore, which was removed in this release.

New configuration class for infrastructure beans

In this release, a new configuration class named DefaultBatchConfiguration can be used as an alternative to using @EnableBatchProcessing for the configuration of infrastrucutre beans. This class provides infrastructure beans with default configuration which can be customized as needed. The following snippet shows a typical usage of this class:

@Configuration
class MyJobConfiguration extends DefaultBatchConfiguration {

	@Bean
	public Job job(JobRepository jobRepository) {
		return new JobBuilder("myJob", jobRepository)
				//define job flow as needed
				.build();
	}

}

In this example, the JobRepository bean injected in the Job bean definition is defined in the DefaultBatchConfiguration class. Custom parameters can be specified by overriding the corresponding getter. For example, the following example shows how to override the default character encoding used in the job repository and job explorer:

@Configuration
class MyJobConfiguration extends DefaultBatchConfiguration {

	@Bean
	public Job job(JobRepository jobRepository) {
		return new JobBuilder("job", jobRepository)
				// define job flow as needed
				.build();
	}

	@Override
	protected Charset getCharset() {
		return StandardCharsets.ISO_8859_1;
	}
}

Transaction support in JobExplorer and JobOperator

This release introduces transaction support in the JobExplorer created through the JobExplorerFactoryBean. It is now possible to specify which transaction manager to use to drive the ready-only transactions when querying the Batch meta-data as well as customizing the transaction attributes.

The same transaction support was added to the JobOperator through a new factory bean named JobOperatorFactoryBean.

Batch Testing Configuration Updates

Spring Batch 5 includes the following testing configuration updates:

Removal of autowiring from test utilities

Up to version 4.3, the JobLauncherTestUtils and JobRepositoryTestUtils used to autowire the job under test as well as the test datasource to facilitate the testing infrastructure setup. While this was convenient for most use cases, it turned out to cause several issues for test contexts where multiple jobs or multiple datasources are defined.

In this release, we introduced a few changes to remove the autowiring of such dependencies in order to avoid any issues while importing those utilities either manually or through the @SpringBatchTest annotation.

Migration to JUnit Jupiter

In this relese, the entire test suite of Spring Batch has been migrated to JUnit 5. While this does not impact end users directly, it helps the Batch team as well as community contributors to use the next generation of JUnit to write better tests.

New features

Improved Java records support

The support for Java records as items in a chunk-oriented step has initially been introduced in v4.3, but that support was limited due to the fact that v4 has Java 8 as a baseline. The initial support was based on reflection tricks to create Java records and populate them with data, without having access to the java.lang.Record API that was finalised in Java 16.

Now that v5 has Java 17 as a baseline, we have improved records support in Spring Batch by leveraging the Record API in different parts of the framework. For example, the FlatFileItemReaderBuilder is now able to detect if the item type is a record or a regular class and configure the corresponding FieldSetMapper implementation accordingly (ie RecordFieldSetMapper for records and BeanWrapperFieldSetMapper for regular classes). The goal here is to make the configuration of the required FieldSetMapper type transparent to the user.

Batch tracing with Micrometer

With the upgrade to Micrometer 1.10, you can now get batch tracing in addition to batch metrics. Spring Batch will create a span for each job and a span for each step within a job. This tracing meta-data can be collected and viewed on a dahsboard like Zipkin for example.

Java 8 features updates

We took the opportunity of this major release to improve the code base with features from Java 8+, for example:

  • Use default methods in interfaces and deprecate "support" classes (see issue 3924)

  • Add @FunctionalInterface where appropriate in public APIs (see issue 4107)

Support for SAP HANA a job repository in Spring Batch

This release introduces the support of SAP HANA as an additional supported database for the job repository.

New Maven Bill Of Materials for Spring Batch modules

This feature has been requested several times and is finally shipped in v5. It is now possible to use the newly added Maven BOM to import Spring Batch modules with a consistent version number.

UTF-8 by default

Several issues related to characters encoding have been reported over the years in different areas of the framework, like inconsitent default encoding between file-based item readers and writers, serialization/deserialization issues when dealing with multi-byte characters in the execution context, etc.

In the same spirit as JEP 400 and following the UTF-8 manifesto, this release updates the default encoding to UTF-8 in all areas of the framework and ensures this default is configurable as needed.

Native support

The effort towards providing support to compile Spring Batch applications as native executables using the GraalVM native-image compiler has started in v4.2 and was shipped as experimental in v4.3.

In this release, the native support has been improved significantly and is now considered out of beta.

Improved documentation

In this release, the documentation was updated to use the Spring Asciidoctor Backend. This backend ensures that all projects from the portfolio follow the same documentation style. For consistency with other projects, the reference documentation of Spring Batch was updated to use this backend in this release.

Pruning

Spring Batch 5 removes a number of items that are no longer needed, including:

API deprecation and removal

In this major release, all APIs that were deprecated in previous versions have been removed. Moreover, some APIs have been deprecated in v5.0 and are scheduled for removal in v5.2. Finally, some APIs have been moved or removed without deprecation for practical reasons.

Please refer to the migration guide for more details about these changes.

SQLFire Support Removal

SqlFire has been announced to be EOL as of November 1st, 2014. The support of SQLFire as a job repository was deprecated in version v4.3 and removed in version v5.0.

JSR-352 Implementation Removal

Due to a lack of adoption, the implementation of JSR-352 has been discontinued in this release.