`@Csv{File}Source`: document that extra chars after closing quote are no longer allowed

[vdmitrienko]

While working on #4692, I noticed FastCSV does not allow extra characters after a closing quote.

This code:

@ParameterizedTest
@CsvSource(value = "'foo'bar")
void extraCharAfterQuote(String argument) {
}

throws the following exception:

org.junit.jupiter.params.provider.CsvParsingException: Failed to parse CSV input configured via...
Caused by: org.junit.jupiter.params.shadow.de.siegmar.fastcsv.reader.CsvParseException: 
Exception when reading first record
Caused by: org.junit.jupiter.params.shadow.de.siegmar.fastcsv.reader.CsvParseException: 
Unexpected character after closing quote: 'b' (0x62)

This behavior was allowed by the uniVocity-based implementation, so we should either document this behavior as a Breaking Change or relax the restriction, if possible.

---

@osiegmar, If I understand correctly, this might be supported via allowExtraCharsAfterClosingQuote(). However, this setting doesn't appear to be compatible with the RelaxedParser that we currently use.

java.lang.IllegalStateException: allowExtraCharsAfterClosingQuote is not supported in relaxed mode

Unfortunately, switching to a different parser is not an option, since we need to preserve trimming of whitespaces around quotes.

Is there any known workaround or alternative way to allow extra characters after a closing quote in this context?

Deliverables

• The change is documented in the Release Notes.

[vdmitrienko]

PR with documentation update: #4694

[osiegmar]

The allowExtraCharsAfterClosingQuote option in FastCSV's strict parser exists mainly for backward compatibility—it was essentially the predecessor of trimWhitespacesAroundQuotes, which was introduced with the relaxed parser. Both options enable parsing of malformed CSV. While I can see the benefit of trimWhitespacesAroundQuotes (for example, making test data easier to read), I don't see benefits for allowExtraCharsAfterClosingQuote. Especially when both options could be enabled, the expected parsing result is unclear, as there is no standard or consensus on how to handle such cases. For the moment, I'd like to keep the parsing error as it is, but I am open to discuss this further if there is a strong case for it.