Was the Assert.notNull check in RecordFieldSetMapper (mapFieldSet) intentionally added for types where null is a valid value?

[ahmad-abed-alhamid]

Hi,

After migrating to Spring Batch 6.0.3, we noticed that RecordFieldSetMapper no longer accepts null values for types where null is a valid value (Long, Integer, etc.).

When reading a CSV where a field is empty/blank, e.g. " ", the SimpleTypeConverter correctly converts it to null for Long. But the Assert.notNull added in commit 62c4cbf rejects this value, causing an IllegalArgumentException.

In Spring Batch 5, null was accepted for these types and this worked correctly.

Was this change intentional? For primitive types, rejecting null makes sense, but for types where null is a valid value, this causes valid data to be rejected. Should I create an issue for this with a proper example?

Thanks!

[Seongwonp]

Yeah, your understanding was correct — this was a regression, not an intentional restriction on nullable reference types.

It was later tracked as #5392 and fixed by #5393. The fix was included in the Spring Batch 6.0.4 milestone.

The Assert.notNull check was introduced as part of the JSpecify nullability refinement, but it was too strict because it also rejected valid null results for reference types such as Long, Integer, BigDecimal, and LocalDate.

Primitive components still cannot receive null, of course, but nullable reference components should behave as they did in Spring Batch 5.

So upgrading from 6.0.3 to 6.0.4 or later should resolve this without needing a custom mapper or workaround.

Nice catch and great minimal reproduction! :)