Pass normalized separator in CsvSchema.withArrayElementSeparator (avoid null state / NPE)

[uttam12331]

Summary

CsvSchema.withArrayElementSeparator(String separator) normalizes a null argument to "" in the local sep and uses sep for the equality check, but then passes the raw separator to the copy constructor:

public CsvSchema withArrayElementSeparator(String separator) {
    String sep = separator == null ? "" : separator;
    return (_arrayElementSeparator.equals(sep)) ? this : new CsvSchema(_columns, _features,
        _columnSeparator, _quoteChar, _escapeChar, _lineSeparator, separator, // <-- should be `sep`
        _nullValue, _columnsByName, _anyPropertyName);
}

The copy constructor stores the value directly, so withArrayElementSeparator(null) leaves _arrayElementSeparator == null.

Impact

This breaks the field's non-null invariant:

• hasArrayElementSeparator() does return !_arrayElementSeparator.isEmpty(); → NullPointerException.
• A subsequent withArrayElementSeparator(...) call NPEs on _arrayElementSeparator.equals(sep).

Every sibling builder stores exactly the value it compared against (e.g. withColumnSeparator compares _columnSeparator == sep and constructs with sep); withArrayElementSeparator is the only one that compares sep but constructs with separator.

Fix

Pass the already-normalized sep:

-            _columnSeparator, _quoteChar, _escapeChar, _lineSeparator, separator,
+            _columnSeparator, _quoteChar, _escapeChar, _lineSeparator, sep,

Tests

Added CsvSchemaTest.testWithArrayElementSeparatorNull, which sets a separator, clears it with withArrayElementSeparator(null), and asserts hasArrayElementSeparator() returns false (and does not throw) — this fails with an NPE on the current code and passes with the fix.

Happy to add a release-notes/CREDITS entry or sign the CLA if needed.

[cowtowncoder]

Sounds good! CLA needed if not sent before -- adding release notes would be great too.

But one question/suggestion: might make sense to target 2.21 as backport (2.21 latest LTS version)?
I can then merge forward to 2.22 -> 2.x -> 3.1 et.

[uttam12331]

Thanks @cowtowncoder! Retargeted this to 2.21 and added the VERSION-2.x and CREDITS-2.x entries under 2.21.6 so it can merge forward as you described. Happy to adjust the release-notes wording if you'd prefer it phrased differently. I'll get the CLA sent over.

[uttam12331]

I've filled and signed the 2026 ICLA (CLA-jackson-2026.pdf). Since the newer CLA file doesn't state a submission address, what's the best way to get it to you — email it, or attach it here?

[cowtowncoder]

@uttam12331 email to "cla" at fasterxml dot com.