Spring Batch 6.1.0-M1 - Job Repository Deserialization Allowlist

Spring Batch v6.1.0-M1 landed on 21 August 2026 as the first milestone of the 6.1 line. GitHub did not flag the tag as a prerelease. The change that matters for anyone who restarts jobs from the job repository is a deserialization allow list on DefaultExecutionContextSerializer and a trusted class check in JobParameterDeserializer.

The full release notes and downloads are on the GitHub release page.

Treat the M1 suffix as a milestone regardless of the GitHub prerelease bit. Keep this build off production job repositories until restart and parameter read paths have been exercised.

DefaultExecutionContextSerializer still writes Base64 Java serialization into the job repository. deserialize now installs an ObjectInputFilter on the ObjectInputStream before readObject.

The default pattern is DEFAULT_FILTER_PATTERN. It accepts java.lang.*, java.util.*, the concurrent and time packages, java.math.*, java.sql.*, java.net.URL, javax.xml.namespace.QName, and org.springframework.batch.**. The pattern ends with !*, so every other class is rejected.

A type outside that list fails with InvalidClassException, wrapped in IllegalArgumentException. The unit test uses java.util.regex.Pattern as the rejected example. Serialize a Pattern into the context and the default filter refuses to read it back.

That is the tradeoff. A poisoned BATCH_STEP_EXECUTION_CONTEXT row can no longer load an arbitrary class through the default serializer. A step that stored a domain type in the execution context will fail on restart until the filter is widened with setObjectInputFilter. Do not copy the default pattern into application code and edit it in place. Build a filter that extends the published constant and install it on the serializer bean.

This is issue #5497 in the notes. The notes call it “incorrect deserialization”. The code change is an allow list, not a format change. Existing Base64 payloads still parse if every class in the stream is already on the list.

The notes list a second deserializer fix as JobParameterDeserializer (#5498). The check sits in the Jackson 2 execution context serializer path. Before Class.forName(type), the type string must be in TrustedTypeIdResolver.TRUSTED_CLASS_NAMES. A miss throws IllegalArgumentException with the text is not in the trusted classes list for JobParameter deserialization.

Same class of bug, different codec. Job parameters that used a custom type and survived in repository rows, or in a nested JobStep context, can now fail on read. JDK types that were already trusted continue to round trip.

Operators who already moved off the Jackson 2 serializer should confirm whether this inner class is still on their read path. The notes do not describe a matching change on the Jackson 3 serializer. Do not assume the allow list landed in both codecs.

The rest of the tag is a dependency bump onto the 6.1 milestone train:

  • Spring Framework 7.1.0-M1
  • Spring Integration 7.2.0-M1
  • Spring AMQP 4.2.0-M1
  • Spring Kafka 4.2.0-M1
  • Spring Data 2026.1.0-M1
  • Micrometer 1.18.0-M1

Those versions are themselves milestones. A job that talks to Kafka or AMQP through Spring Batch integration APIs now compiles against that train. This tag is not a drop in replacement for a 6.0.x line.

The notes also list a FlatFileItemReader malformed input fix (#5496). That work is a record accumulator bound, not a parser rewrite. It is secondary if you are reading this tag for job repository safety. CSV and JSON record jobs still pick it up because it ships in the same artifact.

Treat v6.1.0-M1 as a milestone. GitHub’s prerelease bit is off. The version string is still M1.

Before promoting a build:

  • Restart a job that stores custom types in the execution context. If deserialize throws InvalidClassException, call setObjectInputFilter with an extended pattern.
  • Replay a job whose parameters include a type outside the JDK through JobParameterDeserializer.
  • Do not mix this BOM with Spring Framework 7.0. The notes pin Framework 7.1.0-M1.

No schema migration is listed. The blast radius is read path correctness and class loading, not table shape. Jobs that only store strings, numbers, and Spring Batch types in the context should restart as before.