Scott Conway

No worries - I cannot count the number of times I have been personally burned by overriding transitive dependencies and so I am not surprised when I get a couple of these tickets every year. I was just surprised that I had two this close together. Scott :)

Hello Laurent. Make sure you are using version 5.12.0 as that is using 3.18.0. If you are using 5.12.0 then look at https://sourceforge.net/p/opencsv/feature-requests/175/ for possible solution. The snapshot version does use 3.20.0 but it is just dependency updates thus far so there has not been a reason to update. Here again if you want to force 3.20.0 then look at the above feature request for the solution. Hope that helps. Scott Conway :)

Added a test with a newline.

opencsv modifies BeanUtils shared instance which might cause unexpected behaviors

Hello Felipe The defaults have been there since 2018 and we have tried twice to modify this class and finally had to revert it back to the current version. https://sourceforge.net/p/opencsv/bugs/242/ https://sourceforge.net/p/opencsv/bugs/253/ The biggest issue is that the current BeanUtilsBean.getInstance() doesn't just return the current instance with the current converters - it unregisters all the current converters. When created there was no way of determining if there was converters already...

Sigh - I had a little free time and wanted to see if it was possible to use the validators that we added a few years back because of all the requests to add custom processing or custom validation - https://opencsv.sourceforge.net/#processors_and_validators. I knew it would not work but wanted to try the LineValidator. The issue is the LineValidator validates a single line read by Java - not a single record/row. So a string with a newline inside it requires two Java reads and thus calls the validator...

Just added simplifed test for Bug 270

okay - I did just take a quick copy of your first test and modified it to just use the existing parser so it is always expecting the lientent result and I now see the issues you are talking about and I am shocked this has stayed in so long without someone bringing it up.... well maybe not - it is most likely that all the data before was programatically generated correctly to the rfc4180 specification so no one ever tried a hand parsed or partially malformed csv file. But it does break both rule 6...