Platform independent way of writing/sending CRLF

[Timo Ahokas]

What would be an OS independent way of sending a CRLF (carriage return line feed) at the end of a string (as required by some FTP and other Internet protocols)? Using "\n" depends on the platform, "\r" works ok for CR (0D) but there doesn't seem to be anything for writing a plain linefeed LF (0A). I've tried writing the characters using the \xxx syntax, (\015\012), but even this produces different output depending on the OS. How can I be certain that I only write a plain CRLF?

[Jeroen Wenting]

why not simply write "\0x0D\0x0A"?

[Peter Chase]

It is my understanding that the correct way to get the platform's line separator is: -

System.getProperty("line.separator");

I tend to put this value into a public constant somewhere, to avoid repeating this code again and again.
Additionally, some OutputStream and Writer classes have the ability to write a new-line, which again will be the correct one for the platform.

[Jim Yingst]

Any time you're communicting across a network between two different machines which do not necessariy use the same line sparator, do not use System.getProperty("line.separator"), or a PrintWriter with println(). These use the line separator of the machine you're running on. Other mahcines may not understand. If you're using FTP which expects a carriage return and line feed, send a carriage return and line feed, which are conveniently expressed in Java as
"\r\n"
or equivalently (but less readably) as Jeroen suggests
"\0x0D\0x0A"
Using "\n" depends on the platform
A '\n' is a 0x0A on any platform, if you're using Java. Whether or not that's what the system expects depends on what protocol you're using. If you're using FTP and it's expecting \r\n, then \n by itself probably won't do anything.
"\r" works ok for CR (0D) but there doesn't seem to be anything for writing a plain linefeed LF (0A).
Really, that's what \n is. If it's not working, then whatever you're interfacing with isn't really looking for a linefeed. Or there's some sort of dos/unix converter somewhere in the pipeline, maybe.
I'd suggest posting exactly what the code looks like that you use to append "\r\n" to the string and send it. And what exactly do you observe which tells you that it doesn't work?