Revisit the default configuration of ExecutionContextSerializer with EnableBatchProcessing

[fmbenhassine]

As of v4, the Jackson2ExecutionContextStringSerializer is used as the default (de)serializer when using @EnableBatchProcessing. While Jackson is definitely one of the best json processing libraries in the Java ecosystem, it has several issues:

• Several CVEs was reported against Jackson since it was introduced in Spring Batch in v4 five years ago. This caused us a lot of maintenance effort/burden to release new versions with high SLA.
• It happens that Jackson does not respect semantic versioning. While we understand that semver is not easy to apply rigorously, we have been hit several times by non-backward compatible changes in Jackson's patch and minor versions.
• This is related to the previous point. The non respect of semver from Jackson caused us incompatibilites with Spring Boot releases, given the difference in the release cadence between Spring Boot and Spring Batch.

Goals

For all the reasons mentioned above, we are intending to:

• change the default execution context serializer to a different implementation, and make the choice of Jackson as opt-in instead of opt-out (ie Jackson should become an optional dependency).
• Add another implementation of ExecutionContextSerializer based on Google's Gson, to give our users the choice between at least two implementations out-of-the-box.

Non Goals

There is no plan to deprecate or remove the current Jackson2ExecutionContextStringSerializer.

[mdeinum]

Maybe introduce (and document) an algorithm like Spring Boot does when selecting a DataSource to use depending on what is available on the classpath?

[fmbenhassine]

@mdeinum That's a good idea! However, I would let this kind of features (based on classpath scanning, etc) to Spring Boot.

The goal here is to change the default execution context serializer and make Jackson optional. Any improvement to the way the serializer is selected should be done in another issue.