Spring Batch 6.1.0-M2の変更点を実務視点で解説：MongoDB対応と非同期処理、API移行の注意点

Java / Spring

Spring Batch 6.1.0-M2が公開

Spring Batch 6.1.0-M2がMaven Centralで公開されました。6.1.0-M1をベースに、MongoDBジョブリポジトリの運用性向上、非同期処理APIの依存関係整理、リソース指定の簡素化、ビルダーAPIのコンパイル時安全性向上などが盛り込まれています。

一方で、依存関係の更新や複数APIの非推奨化、ビルダーのソース・バイナリ互換性に関わる変更も含まれます。6.1正式版へのアップグレードを検討するチームにとっては、機能追加だけでなく、既存コードとビルド環境への影響を確認するためのマイルストーンです。

依存関係の更新

Spring関連の依存関係は、次のマイルストーン版へ更新されています。

コンポーネント バージョン
Spring Framework 7.1.0-M2
Spring Integration 7.2.0-M2
Spring Data 2026.1.0-M2
Spring LDAP 4.2.0-M1
Spring AMQP 4.2.0-M2
Spring Kafka 4.2.0-M2
Micrometer 1.18.0-M2

本番環境での採用を急ぐよりも、アプリケーションが利用しているSpring Bootや各種Springプロジェクトとの組み合わせを、テスト環境で検証することが重要です。特に、Spring Batchだけを個別に更新する運用では、依存関係の解決結果が従来と変わる可能性があります。

MongoDBジョブリポジトリにコレクション接頭辞

MongoDBのジョブリポジトリで、JDBCジョブリポジトリのテーブル接頭辞に相当するコレクション接頭辞を設定できるようになりました。

@EnableBatchProcessing
@EnableMongoJobRepository(collectionPrefix = "MY_APP_")
class MyJobConfiguration {
    // job definition omitted
}

接頭辞のデフォルト値は BATCH_ です。そのため、既存アプリケーションでは設定を変更しない限り、従来の命名を維持できます。

この変更は、1つのMongoDBデータベースを複数のアプリケーションや環境で共有する場合に有効です。例えば、アプリケーションごとに接頭辞を分けることで、ジョブメタデータの名前空間を分離できます。

  • アプリケーションごとにジョブリポジトリを分離する
  • 開発環境、検証環境、本番環境のコレクションを区別する
  • 同一データベース内でテナント単位の名前空間を設ける

ただし、接頭辞を変更すると参照対象となるコレクションも変わります。既存のジョブ実行履歴を引き継ぐアップグレードでは、設定変更とデータ移行の扱いを同時に設計する必要があります。

非同期処理APIがspring-batch-coreへ移動

次のクラスが spring-batch-integration から spring-batch-coreへ移動しました。

  • AsyncItemProcessor
  • AsyncItemWriter
  • ChunkTaskExecutorItemWriter

これらのAPIは、主に TaskExecutorを利用した非同期処理やローカルチャンク処理を提供するもので、Spring Integrationへの依存を必要としません。spring-batch-coreで利用できるようになることで、非同期処理だけを目的に spring-batch-integrationとその推移的依存関係を追加する必要がなくなります。

パッケージは org.springframework.batch.core.step.itemです。既存コードでは、import文や依存関係の見直しが必要になります。

import org.springframework.batch.core.step.item.AsyncItemProcessor;
import org.springframework.batch.core.step.item.AsyncItemWriter;

従来の spring-batch-integration側のクラスは、後方互換性のため非推奨サブクラスとして維持されます。ただし、今後の新規実装では spring-batch-core側のAPIを利用する構成へ寄せるのが移行しやすい方針です。

依存関係を整理する際には、単にライブラリを削除するのではなく、次の点を確認します。

  • Spring Integration固有のコンポーネントを別の処理で利用していないか
  • import先をorg.springframework.batch.core.step.itemへ変更できるか
  • 非同期処理のスレッド数、トランザクション境界、エラー処理が期待どおりか
  • 既存のジョブ実行結果や再実行動作に変化がないか

RepositoryItemWriterにフラッシュ対応

RepositoryItemWriterは、チャンクの書き込み後に基盤となるSpring Dataリポジトリをフラッシュできるようになりました。

リポジトリ側に保存とフラッシュを同時に行うメソッドがある場合は、例えば saveAllAndFlushのようなメソッドを指定する方式を利用できます。また、サブクラスで新しい flushメソッドをオーバーライドして、独自のフラッシュ処理を実装することも可能です。

この変更は、JPAなどで書き込み内容をチャンク単位で確実に同期したいケースで検討しやすくなります。一方、フラッシュはデータベースへの反映処理を発生させるため、性能とのバランスが必要です。

  • チャンクサイズとフラッシュ頻度を確認する
  • 大量データ処理でデータベース負荷が増えないか測定する
  • 失敗時にどの単位で再実行されるかを確認する
  • トランザクション境界とリポジトリの実装を確認する

リソースベースのReaderでパターンを直接指定

MultiResourceItemReaderBuilderで、リソースをあらかじめ解決して配列やリストとして渡す代わりに、ロケーションパターンを直接指定できるようになりました。

new MultiResourceItemReaderBuilder<String>()
    .resourcePattern("classpath:data/input/file-*.txt");

また、ResourcesItemReaderBuilderにも同様の能力が追加されています。入力ファイルをクラスパスやファイルシステム上のパターンで扱うジョブでは、設定コードやリソース解決処理を簡素化できます。

ファイルの追加・削除によって対象範囲が変わる処理では、パターンに一致するファイルの並び順や、同一ファイルを再処理した場合の挙動が運用上のポイントになります。移行時には、従来のリソース解決処理と新しいパターン指定で対象ファイルが一致することをテストしてください。

ビルダーAPIの不正な組み合わせをコンパイル時に検出

次のビルダーでは、互いに排他的な設定メソッドの組み合わせを、実行時の build()ではなくコンパイル時に検出できるよう、ステージドDSLが導入されました。

  • FlatFileItemReaderBuilder
  • FlatFileItemWriterBuilder
  • JdbcBatchItemWriterBuilder

これまでは、排他的な2つの設定を両方呼び出しても、build()の時点まで問題が分からない場合がありました。新しいAPIでは、設定の段階に応じた型を使うことで、無効な組み合わせをコンパイラが拒否します。

この変更は、単純な fluent call chainで利用しているコードであれば、再コンパイルによって対応できるケースがあります。しかし、ビルダーの戻り値を具象的なビルダークラス型の変数へ格納しているコードでは、ソース互換性やバイナリ互換性に影響する可能性があります。

// 戻り値を具象型の変数へ保存しているコードは影響を受ける可能性がある
var builder = new FlatFileItemReaderBuilder<String>();

アップグレード時には、次のようなコードを検索するのが実務的です。

  • ビルダーをフィールドやローカル変数に保持している箇所
  • ビルダーの型を明示している箇所
  • 共通メソッドの引数や戻り値でビルダー型を扱っている箇所
  • 複数の設定メソッドを条件分岐で呼び出している箇所

一方、次のようなメソッドチェーン中心のコードは、型の変化による影響を受けにくい構造です。

new FlatFileItemReaderBuilder<String>()
    .name("reader")
    // 必要な設定
    .build();

実際のアップグレードでは、コンパイルエラーを単に修正するだけでなく、排他的な設定が意図どおり選択されているかを確認することが重要です。

変換サービスの標準化

ジョブリポジトリのデフォルト変換サービスは、Spring Frameworkの DefaultFormattingConversionServiceをベースに構築されるようになりました。新たに ConversionServiceFactoryユーティリティが提供され、従来の手書きコンバーター群から、Springが提供する変換・フォーマット機能を活用する構成へ整理されています。

ジョブパラメータの既存フォーマットは維持される一方、利用できるコンバーターやフォーマッターの範囲が広がります。従来の日時コンバーターは非推奨となり、次のファクトリメソッドが移行先になります。

ConversionServiceFactory#createConversionService()

ジョブパラメータを文字列から日時型などへ変換しているアプリケーションでは、既存の値が同じ型・同じ時刻として解釈されることを回帰テストで確認するとよいでしょう。

非推奨になったAPIと7.0に向けた準備

6.1.0-M2では、いくつかのAPIが非推奨になりました。これらは7.0で削除される予定です。

  • Apache Derbyサポート
  • 旧来の日時コンバーター
  • StepExecution#getJobExecutionId()
  • StepExecution#getJobParameters()
  • JobExecution#getJobInstanceId()
  • ジョブ名やステップ名が不明な場合に正確な値を返せない一部のカウントメソッド

非推奨APIは、コンパイル警告を抑制して使い続けるのではなく、6.1対応の段階で移行候補を整理しておくべきです。特に共通ライブラリや複数ジョブから呼び出されるユーティリティに非推奨APIが残っていると、7.0移行時の影響範囲が大きくなります。

6.1正式版に向けたアップグレードチェックリスト

M2を検証環境へ導入する場合は、機能テストだけでなく、依存関係と互換性を含めて確認します。

  1. 依存関係の解決結果を確認し、Spring FrameworkやSpring Dataなどの更新による影響を確認する
  2. MongoDBジョブリポジトリを利用している場合、コレクション接頭辞と既存メタデータの対応を確認する
  3. spring-batch-integrationから非同期処理APIを利用しているコードのimportと依存関係を見直す
  4. RepositoryItemWriterのフラッシュによる性能、トランザクション、再実行動作を検証する
  5. リソースパターン指定へ移行する場合、対象ファイルと並び順が従来と一致するか確認する
  6. ビルダーを変数へ格納しているコードを洗い出し、コンパイルエラーと型の変更を確認する
  7. 非推奨APIの利用箇所を一覧化し、7.0までの移行計画を作成する
  8. ジョブの再実行、スキップ、リスタート、失敗時のロールバックを確認する

まとめ

Spring Batch 6.1.0-M2は、単なる機能追加にとどまらず、ジョブリポジトリの運用性、非同期処理の依存関係、入力リソースの設定方法、ビルダーAPIの安全性を見直すリリースです。

特に、MongoDBを複数アプリケーションや複数環境で共有しているチームにとって、コレクション接頭辞は運用設計に直結します。また、非同期処理APIの spring-batch-coreへの移動は、依存関係を小さくしたいアプリケーションにメリットがあります。

一方で、ビルダーAPIのステージドDSLや非推奨APIの追加は、アップグレード時にソースコードの確認を必要とします。6.1正式版を見据えるなら、M2を使ってコンパイル、回帰テスト、性能テストを実施し、7.0で削除されるAPIも含めて段階的に移行することが、安定したバッチ基盤につながります。

出典： Spring公式ブログ

タイトルとURLをコピーしました