On behalf of the team and all contributors, I am pleased to announce that Spring Batch 5.0.0-M7 is now available from our milestone repository.

The main theme of this milestone is the improvement of job parameters handling in Spring Batch. Two main changes were introduced in this release:

• Add support to use any type as a job parameter
• Improve job parameters conversion

This blog post walks through these two major changes in details. For the complete list of changes, please check the release notes.

Add support to use any type as a job parameter

Up to version 4, Spring Batch supported only 4 types that can be used as job parameters, which are long, double, String and Date. While this was convenient to simplify job parameters handling on the framework's side, it turns out to be constraining on the user's side. For instance, what if one wants to use a boolean or a custom type as a job parameter? This required additional conversions to one of the supported types in Spring Batch, which quickly became inconvenient to users.

In this release, we have added support to use any type as a job parameter. The main change behind this improvement is the following:

---public class JobParameter implements Serializable {
+++public class JobParameter<T> implements Serializable {

---   private Object parameter;
+++   private T value;

---   private ParameterType parameterType;
+++   private Class<T> type;

}

This change has an impact on how job parameters are persisted in the database. Please check the migration guide for database schema changes. The fully qualified name of the type of the parameter is now persisted as a String, as well as the parameter value. String literals are converted to the parameter types with the standard Spring conversion service. The standard conversion service can be enriched with any required converter to convert user specific types to and from String literals.

Improve job parameters conversion

The default notation of job parameters in v4 was specified as follows:

[+|-]parameterName(parameterType)=parameterValue

where parameterType is one of [string,long,double,date]. While this notation was concise, it showed several limitations as it does not play well with environment variables and is not friendly with Spring Boot.

In v5, we have changed the default notation as follows:

parameterName=parameterValue,parameterType,identificationFlag

where parameterType is the fully qualified name of the type of the parameter. For example, the following key/value pair:

schedule.date=2022-12-12,java.time.LocalDate

will be converted to an identifying job parameter of type java.time.LocalDate with the value 2022-12-12. Note how the identification flag is optional and defaults to true. This new default notation is well suited for the majority of use cases, but it might not be convenient when the value contains a comma for example. For this reason, we have introduced a new "extended" notation that is inspired by Spring Boot's Json Application Properties and which is specified as follows:

parameterName='{"value": "parameterValue", "type":"parameterType", "identifying": "booleanValue"}'

where parameterType is the fully qualified name of the type of the parameter. Spring Batch provides the JsonJobParametersConverter to support this notation. It is of course possible to support any other notation by implementing the strategy interface JobParametersConverter and registering the custom implementation in the job repository and job explorer.

We believe these two major changes of job parameters handling in Spring Batch are more convenient, more flexible and less prone to errors.

Feedback

I would like to thank all contributors who had a role in this release! As we continue our work on Spring Batch 5, we look forward to your feedback on Github, Twitter and StackOverflow.

Spring Batch Home|Source on Github|Reference documentation