I have been fixing some minor issues in [csv] found during release of 1.7. The fingbugs report for the release had 1 issue (see site [1]).
When fixing this issue I found findbugs reports that CSVRecord has a field that is not Serializable. This issue is not in the project report on the site. If I checkout either the tag commons-csv-1.7 or commons-csv-1.7-RC1 then run findbugs it finds this error. So this is a strange mismatch between the site report not finding this bug and the local site report finding this bug. When I reviewed the release candidate sadly I looked at the site report so missed this. So CSVRecord was Serializable in <1.7 but now has a new field that is not Serializable. CSV-239 introduced a new field into the CSVRecord: the CSVParser that originates the record. To make the CSVParser Serializable requires the following also become Serializable: Lexer CSVRecordIterator Token The Lexer is not an issue. The non-static inner class CSVRecordIterator is a FindBugs warning when made Serializable as it will serialise the outer class. The Token is an issue as it contains ExtendedBufferedReader which extends a non Serializable BufferedReader and the standard java Readers are not Serializable. So a fix would have to revisit CSV-239. This added: public CSVParser getParser(); So the parser cannot be removed as it is part of the API. A possible solution would be to make part of the CSVParser Serializable that is required to support the CSVRecord functionality that depends on the parser. This is the header map. The rest can be made transient (such as the Reader) as these fields are not required to restore functionality to CSVRecord after deserialisation. Thoughts? Alex [1] https://commons.apache.org/proper/commons-csv/findbugs.html <https://commons.apache.org/proper/commons-csv/findbugs.html>
