Spring Batch 6.0 GA is out! #5156
fmbenhassine
announced in
Announcements
Replies: 3 comments
-
|
Congratulations on this incredible release! 🎉
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Congratulations to Mahmoud and the team on this massive release! 🚀 |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Congratulations on this major release! 🎉 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Dear Spring Batch community,
On behalf of the team and all contributors, I am pleased to announce the release of Spring Batch 6! This major version is the culmination of three years of work and I would like to thank all contributors who worked on this release 🙏 It's almost a decade that I have been working on Spring Batch, and I have never been as excited about a release as this one. The release notes of v6.0 GA is definitely the longest one I have ever written!
The reason I am excited about this release is that it is the first major release that really addresses major issues with major changes 😅 Please note that almost all decisions were made based on the feedback from our OSS community (through GitHub issues, discussions, polls and StackOverflow, Twitter, cold emails! etc) as well as our paying customers.
I am not going to repeat all features from the What's new page, but I wanted to quickly elaborate on the main technical challenges that were addressed in this release and why I believe this is a great foundation for the future of Spring Batch.
Redesigned domain model
From the very early days of the project, the domain model of Spring Batch was criticized for being mutable (see #3534, #1870). In Spring Batch 6, the domain model was redesigned to address these concerns by making key entities partially immutable (as described in "7.1 Partially immutable entities" from the Secure By Design book). I say partially because, by it's nature, the domain model of Spring Batch requires some mutability like setting the end time of a job/step execution for instance, but it's not possible anymore to create an entity without an ID or re-assign the ID of an entity. This change prevents several issues like orphan entities, shallow copies of domain entities, etc.
The model was also redesigned towards better encapsulation of state like for example the job parameter name which is now part of the
JobParameterconcept (see #5010), or the use of Java records which are immutable by design. This redesign is the continuation of the efforts started in Spring Batch 5 to separate the domain model from the persistence model for better separation of concerns.Simplified, null-safe core APIs
For a long time, Spring Batch has been criticized for its complex APIs (#3242 and #2901) and a lot of accidental complexity has been added over the years for no real added value. In fact, the configuration of a non-trivial application required several beans, some functionality was duplicated in several places, and some APIs were not clearly defined which made it hard to understand how to use them properly. These issues were described in more details in #4847, #4833, #4988 and others.
Spring Batch 6 addresses all these problems to make APIs simpler to use and understand. Moreover, several APIs were moved to dedicated packages to better reflect their purpose and for more package cohesion.
Finally, we have reviewed all APIs to make them null-safe by using the jSpecify annotations.
Improved chunk-oriented processing implementation
The implementation of the chunk-oriented processing model suffered from several issues like the lack of proper transaction synchronization, complex state management and concurrency issues. I described this in details in #3950. While we tried hard to maintain this implementation over the years (I personally lost some hair here..😂), it became clear that a redesign was necessary to address these issues properly.
In Spring Batch 6, the chunk-oriented processing model was re-implemented from scratch to address these issues. The new implementation is easier to understand, think about, test and maintain in the long term.
Improved concurrency model
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. Here is the relevant issue that describes these problems in more details: #4955 (I also lost some hair here as well..😂).
Spring Batch 6 revisits that model and comes with a new, simplified approach to concurrency based on the producer-consumer pattern. This new model is more efficient, easier to understand and provides better performance for concurrent executions.
This model also made it easier to introduce a new concurrency technique: local chunking. This technique allows you to process chunks in parallel within the same step execution without the need for partitioning. This is particularly useful for processing large datasets that can be processed in parallel without the overhead of partitioning. You can think of it like remote chunking but with local threads.
Moreover, this new model paves the way for future concurrency improvements in Spring Batch like leveraging structured concurrency (when it will become out of review) and better use of virtual threads.
Improved integration with Spring Boot
We have worked closely with the Spring Boot team to improve the integration of Spring Batch 6 with Spring Boot 4. This includes better, more modular auto-configuration as well feature alignment between both frameworks.
Now with all that being said, I understand that big releases like this one can be challenging to upgrade to, but I strongly believe that these changes were necessary to ensure the long-term sustainability of the project and to provide a solid foundation for future improvements. As with every major overhaul, I am expecting some bumps and corner cases that we may have missed, and our priority for now is stabilising things in 6.0.1 and 6.0.2.
I am committed to help our community to upgrade their applications to Spring Batch 6. Please check the migration guides of Spring Batch 6 and Spring Boot 4 and feel free to open a Migration Support request.
Happy batching!
Best regards,
Mahmoud
Beta Was this translation helpful? Give feedback.
All reactions