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 bean in the application context. The DataSource bean could refer to an embedded database to work with an in-memory job repository.

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.

When no transaction manager is specified, @EnableBatchProcessing used (up to version 4.3) to register a default transaction manager of type org.springframework.jdbc.datasource.DataSourceTransactionManager in the proxy around JobRepository when a DataSource bean is defined in the application context. In this release, the type of the default transaction manager has changed to org.springframework.jdbc.support.JdbcTransactionManager.

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.

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.

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

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

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.

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.

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.

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 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.

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