CODEWITHSUNDEEP
javanewlineportabilitylinefeed
Wolfpack'08
Wolfpack'08

Reputation: 4128

\n and \r seem to work everywhere. Why is line.separator more portable?

I was just perusing through questions, and I found System.getProperty(line.separator) used in place of \n with the author's comment that the code was "portable". Reading through various forums, I've seen two groups:

  1. People who say there's a difference between Linux's and Windows' interpretation of newline characters, and this compensates for that (with no clear evidence).
  2. People who say there's no difference by showing code and output examples, which obviously only applies to that code example and not universally.

My feeling is: it's probably non-standard OS's, like for example your company's industrial scanner's OS for example, where you'll notice a difference. When am I going to see a difference between \n and line.separator? Can you show an example, please? How did you go about discovering where the variation occurs?

Upvotes: 8

Views: 8205

Answers (3)

that other guy
that other guy

Reputation: 123680

Incorrect line endings are a frequent annoyance. For example, this is what Windows Notepad shows when writing a file with \n instead of \r\n (Windows' line.separator):

Notepad with boxes instead of line breaks

Those little boxes were supposed to be line breaks.

The other way around, when \r\n is used in place of \n (Unix' line.separator), is way worse, and breaks shell scripts and config files in weird and wonderful ways.

For example, this is what sh outputs on Debian and derived distros when trying to run a shell script that just contains ls but with \r\n line separators (it looks trashed because the carriage return causes the terminal to overwrite parts of the line):

: not foundsh: ls

There are several questions per day on StackOverflow from people being bitten by this, such as here, here and here.

Upvotes: 8

Sam Hanley
Sam Hanley

Reputation: 4755

Here's the standard line separators by OS: 

Windows: '\r\n'
Mac (OS 9-): '\r'
Mac (OS 10+): '\n'
Unix/Linux: '\n'

What that means is that if you hard code your line separators as \n, you're going to get the expected results in Linux and OS X, but Windows won't recognize the line endings properly. However, by using the more general line.separator to represent your line endings, they'll resolve to whatever the executing operating system's expected implementation of line endings may happen to be.

Upvotes: 11

keshlam
keshlam

Reputation: 8058

If you get this wrong, you WILL mess up your ability to exchange data with other applications. You need to understand when you can get away with assuming that Java will help you... and when you can't.

Linux applications normally use only the linefeed character (\n) as its line break. Windows applications use the combination of carriage return followed by line feed (\n\r).

If you're using high-level Java I/O routines -- if you're going through Readers and Writers which process characters, rather than low-level Streams and especially byte streams -- the libraries will translate \n (which java, by convention, uses internally as its newline) into the platform-appropriate representation. If you're using lower-level functions, you have to be aware of that distinction and Do The Right Thing yourself.

Upvotes: 6

Related Questions