Javadoc for CSVWriter.DEFAULT_LINE_END is wrong
Brought to you by:
aruckerjones,
sconway
Menu
▾
▴
#117 Javadoc for CSVWriter.DEFAULT_LINE_END is wrong
The Javadoc for CSVWriter.DEFAULT_LINE_END says:
Default line terminator uses platform encoding.
This is not correct. DEFAULT_LINE_END is always "\n" (Unix line ending). Using platform encoding would mean using "\r\n" on Windows.
Maybe it would also be helpful to point out that this is not the CSV standard line ending. See #110 "CSVWriter should separate lines with CRLF by default to match CSV standard".
It does say that so I changed it to say "Default line terminator". This project has been around for around ten years and I have a feeling that the value was changed shortly after the "File processes differently on Unix than Windows" defect but the comment was not modified to reflect change.
Would it be helpful to point out that the CSVWriter has a constructor to allow you to set the line terminator? Did you read my response on my rejection of 110 before you sent the merge request? Yes I fully well understand that the standards state /r/n but having been around 10 years I am not going to make a change that effects all users and all currently running implementations. You have to think about everyone.
I have gotten several request on this over the years and for the same reason rejected them all. If you really are bugged that it is not following standards but cannot be bothered to use a constructor that would allow you to set it yourself I invite you to create an RFC4180CompliantCSVWriter that extends CSVWriter except that it uses /r/n (some methods will have to go from private to protected but that is okay) - just make sure it has the same level of unit tests as the CSVWriter (actually you could copy the tests and replace the line terminators.
Do that and I promise you I will seriously merge it in. Because that would have no impact on current users but allow people that want to follow the standards writer that does not disrupt everyone else. And if you extend CSVWriter then future changes should not require two files to change.
Thanks for changing the Javadoc so quickly :-)
Regarding better support for RFC 4180:
I get your point about not chaning the line terminator for compatibility. I think you are right. Also, as far as I know most CSV in the real world is not RFC 4180 compliant. So most parsers should understand any line termination style. So it's a very minor point.
The only reason I want to use RFC 4180 style line endings is because it's a CSV export we do for a customer. And hopefully complying to the RFC will greatly reduce any discussion over the quoting, escaping, line ending, etc.
For my use case, creating a new class RFC4180CompliantCSVWriter would be overkill. I'm happy to use the constructor. Of course you will know best how often this request comes up and if adding such a class makes sense from the project's perspective.
What I would find helpful would be an alternative constant STANDARD_LINE_END or RFC4810_LINE_END that could be passed to constructor. Like the existing constants NO_QUOTE_CHARACTER and NO_ESCAPE_CHARACTER. If you are interested in this, I would be happy to create a merge request.
Thanks for your good work on Opencsv. It's a really helpful library :-)
/*
* RFC 4180 compliant line terminator.
/
public static final String RFC4810_LINE_END = "\r\n";
I just merged it into trunk - it will be a while before I push 3.6 as
popcorn season is starting and I am the troop kernel (every three
months seems to be my stride).
I am glad to hear you are at a job where you work with customers.
that means you understand you cannot just make changes to make one
persons life easier as you could be disrupting everyone else. That is
what is most upsetting about the compliance requests as we have tried
to make it configurable enough that you can get compliance but without
forcing people to stop upgrading. That is why I favored a new class
over changing the existing, or why in the last release I created an
IterableCSVToBean instead of heavily modifying CSVToBean to be
Iterable. That way if an bug is introduced it will not effect current
users when they upgrade. The isClosed issue has really burned me.
Which is also why I loved your solution with the new constant - It
does not change existing behavior but gives something to those who
want to maintain compliance.
Thanks for the suggestion.
:)
On Tue, Aug 4, 2015 at 2:43 AM, Arend v. Reinersdorff arendvr@users.sf.net
wrote:
--
Scott Conway
scott.conway@gmail.com
http://www.conwayfamily.name
Related
Bugs:
#117Great, thank you :-)