このバージョンはまだ開発中であり、まだ安定しているとは見なされていません。最新の安定バージョンについては、Spring Batch ドキュメント 5.2.3 を使用してください！

Spring Batch 6 の新機能

このセクションでは、Spring Batch 6.0 の主な変更点について説明します。変更点の完全なリストについては、リリースノート [GitHub] (英語) を参照してください。

Spring Batch 6.0 には次の機能と改善点が含まれています。

依存関係のアップグレード
バッチインフラストラクチャ構成の改善
チャンク指向処理モデルの新しい実装
新しい並行性モデル
新しいコマンドライン演算子
失敗したジョブ実行を回復する機能
あらゆるステップを停止する機能
Java Flight Recorder による可観測性のサポート (JFR)
廃止と削減

依存関係のアップグレード

このメジャーリリースでは、Spring の依存関係が次のバージョンにアップグレードされます。

Spring Framework 7.0
Spring Integration 7.0
Spring Data 4.0
Spring LDAP 4.0
Spring AMQP 4.0
Spring Kafka 4.0
Micrometer 1.16

バッチインフラストラクチャ構成の改善

バッチインフラストラクチャ構成用の新しいアノテーションとクラス

v6 より前では、@EnableBatchProcessing アノテーションは JDBC ベースのインフラストラクチャに紐付けられていました。これはもはや当てはまりません。基盤となるジョブリポジトリを設定するための 2 つの新しいアノテーション、@EnableJdbcJobRepository と @EnableMongoJobRepository が導入されました。

v6 以降、@EnableBatchProcessing ではバッチインフラストラクチャの共通属性を構成できるようになり、新しい専用アノテーションを使用してストア固有の属性を指定できるようになりました。

これらのアノテーションの使用方法の例を次に示します。

@EnableBatchProcessing(taskExecutorRef = "batchTaskExecutor")
@EnableJdbcJobRepository(dataSourceRef = "batchDataSource", transactionManagerRef = "batchTransactionManager")
class MyJobConfiguration {

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

同様に、DefaultBatchConfiguration に基づくプログラムモデルも更新され、ストア固有の属性を定義するための 2 つの新しい設定クラス（JdbcDefaultBatchConfiguration と MongoDefaultBatchConfiguration）が導入されました。これらのクラスを使用することで、各ジョブリポジトリやその他のバッチインフラストラクチャ Bean の特定の属性をプログラム的に設定できます。

デフォルトでリソースレスのバッチインフラストラクチャ

DefaultBatchConfiguration クラスが更新され、デフォルトで「リソースレス」なバッチインフラストラクチャ（v5.2 で導入された ResourcelessJobRepository 実装に基づく）が提供されるようになりました。これにより、以前はバッチメタデータの保存に必要だったジョブリポジトリ用のインメモリデータベース（H2 や HSQLDB など）が不要になりました。

さらに、ResourcelessJobRepository はデータベース接続やトランザクションを必要としないため、この変更により、メタデータが使用されていない場合のバッチアプリケーションのデフォルトのパフォーマンスが向上します。

最後に、この変更により、メタデータの保存にメモリ内データベースが不要になるため、バッチアプリケーションのメモリフットプリントを削減できます。

バッチインフラストラクチャ構成の簡素化

v6 より前では、複雑な Spring Batch アプリケーションの典型的な設定は非常に複雑で、JobRepository、JobLauncher、JobExplorer、JobOperator、JobRegistry、JobRegistrySmartInitializingSingleton など多くの Bean が必要でした。そのため、たとえば JobRepository と JobExplorer の両方で同じ実行コンテキストシリアライザーを設定するなど、多くの設定コードが必要でした。

このリリースでは、バッチインフラストラクチャの構成を簡素化するためにいくつかの変更が加えられました。

JobRepository は JobExplorer インターフェースを継承するため、別途 JobExplorer Bean を定義する必要はありません。
JobOperator は JobLauncher インターフェースを継承するため、別途 JobLauncher Bean を定義する必要はありません。
The JobRegistry is now optional, and smart enough to register jobs automatically, so there is no need to define a separate JobRegistrySmartInitializingSingleton bean.
The transaction manager is now optional, and a default ResourcelessTransactionManager is used if none is provided.

This reduces the number of beans required for a typical batch application and simplifies the configuration code.

チャンク指向処理モデルの新しい実装

This is not a new feature, but rather a new implementation of the chunk-oriented processing model. This new implementation was introduced as an experimental addition in version 5.1, and is now available as stable in version 6.0.

The new implementation is provided in the ChunkOrientedStep class, which is a replacement for the ChunkOrientedTasklet / TaskletStep classes.

Here is an example of how to define a ChunkOrientedStep by using its builder:

@Bean
public Step chunkOrientedStep(JobRepository jobRepository, JdbcTransactionManager transactionManager,
        ItemReader<Person> itemReader, ItemProcessor<Person, Person> itemProcessor, ItemWriter<Person> itemWriter) {
    int chunkSize = 100;
    return new ChunkOrientedStepBuilder<Person, Person>(jobRepository, transactionManager, chunkSize)
        .reader(itemReader)
        .processor(itemProcessor)
        .writer(itemWriter)
        .build();
}

Moreover, fault-tolerance features were adapted as follows:

The retry feature is now based on the retry functionality introduced in Spring Framework 7 , instead of the previous Spring Retry library
The skip feature has been slightly adapted to the new implementation, which is now only based entirely on the SkipPolicy interface

Here is a quick example of how to use the retry and skip features with the new ChunkOrientedStep:

@Bean
public Step faulTolerantChunkOrientedStep(JobRepository jobRepository, JdbcTransactionManager transactionManager,
        ItemReader<Person> itemReader, ItemProcessor<Person, Person> itemProcessor, ItemWriter<Person> itemWriter) {

    // retry policy configuration
    int maxAttempts = 10;
    var retrybaleExceptions = Set.of(TransientException.class);
    RetryPolicy retryPolicy = RetryPolicy.builder()
        .maxAttempts(maxAttempts)
        .includes(retrybaleExceptions)
        .build();

    // skip policy configuration
    int skipLimit = 50;
    var skippableExceptions = Set.of(FlatFileParseException.class);
    SkipPolicy skipPolicy = new LimitCheckingExceptionHierarchySkipPolicy(skippableExceptions, skipLimit);

    // step configuration
    int chunkSize = 100;
    return new ChunkOrientedStepBuilder<Person, Person>(jobRepository, transactionManager, chunkSize)
        .reader(itemReader)
        .processor(itemProcessor)
        .writer(itemWriter)
        .faultTolerant()
        .retryPolicy(retryPolicy)
        .skipPolicy(skipPolicy)
        .build();
}

Please refer to the migration guide [GitHub] (英語) for more details on how to migrate from the previous implementation to the new one.

新しい並行性モデル

Prior to this release, the concurrency model based on the "parallel iteration" concept required a lot of state synchronization at different levels and had several limitations related to throttling and backpressure leading to confusing transaction semantics and poor performance.

This release revisits that model and comes with a new, simplified approach to concurrency based on the producer-consumer pattern. A concurrent chunk-oriented step now uses a bounded internal queue between the producer thread and consumer threads. Items are put in the queue as soon as they are ready to be processed, and consumer threads take items from the queue as soon as they are available for processing. Once a chunk is ready to be written, the producer thread pauses until the chunk is written, and then resumes producing items.

This new model is more efficient, easier to understand and provides better performance for concurrent executions.

新しいコマンドライン演算子

Spring Batch provided a CommandLineJobRunner since version 1. While this runner served its purpose well over the years, it started to show some limitations when it comes to extensibility and customisation. Many issues like static initialisation, non-standard way of handling options and parameters, lack of extensibility, etc have been reported.

Moreover, all these issues made it impossible to reuse that runner in Spring Boot, which resulted in duplicate code in both projects as well behaviour divergence (like job parameters incrementer behaviour differences) that is confusing to many users.

This release introduces a modern version of CommandLineJobRunner, named CommandLineJobOperator, that allows you to operate batch jobs from the command line (start, stop, restart and so on) and that is customisable, extensible and updated to the new changes introduced in Spring Batch 6.

失敗したジョブ実行を回復する機能

Prior to this release, if a job execution fails abruptly, it was not possible to recover it without a manual database update. This was error-prone and not consistent across different job repositories (as it required a few SQL statements for JDBC databases and some custom statements for NoSQL stores).

This release introduces a new method named recover in the JobOperator interface that allows you to recover failed job executions consistently across all job repositories.

あらゆるステップを停止する機能

As of v5.2, it is only possible to externally stop Tasklet steps through JobOperator#stop. If a custom Step implementation wants to handle external stop signals, it just can’t.

This release adds a new interface, named StoppableStep, that extends Step and which can be implemented by any step that is able to handle stop signals.

Observability with the Java Flight Recorder (JFR)

In addition to the existing Micrometer metrics, Spring Batch 6.0 introduces support for the Java Flight Recorder (JFR) to provide enhanced observability capabilities.

JFR is a powerful profiling and event collection framework built into the Java Virtual Machine (JVM). It allows you to capture detailed information about the runtime behavior of your applications with minimal performance overhead.

This release introduces several JFR events to monitor key aspects of a batch job execution, including job and step executions, item reads and writes, as well as transaction boundaries.

廃止と削減

As with any major release, some features have been deprecated or removed in Spring Batch 6.0. The following changes are worth noting:

All deprecated API and features from previous versions have been removed
Modular configuration through @EnableBatchProcessing(modular = true) has been deprecated
Several API have been deprecated in this version, in order to simplify the core API and reduce its scope

Fore more details, please refer to the migration guide [GitHub] (英語) .