What's up with Java's "%n" in printf?

Question

From a quick google:

There is also one specifier that doesn't correspond to an argument. It is "%n" which outputs a line break. A "\n" can also be used in some cases, but since "%n" always outputs the correct platform-specific line separator, it is portable across platforms whereas"\n" is not.

Please refer https://docs.oracle.com/javase/tutorial/java/data/numberformat.html

Original source

%n is portable across platforms \n is not.

See the formatting string syntax in the reference documentation:

'n' line separator The result is the platform-specific line separator

While \n is the correct newline character for Unix-based systems, other systems may use different characters to represent the end of a line. In particular, Windows system use \r\n, and early MacOS systems used \r.

By using %n in your format string, you tell Java to use the value returned by System.getProperty("line.separator"), which is the line separator for the current system.

Warning:

If you're doing NETWORKING code, you might prefer the certainty of \n, as opposed to %n which may send different characters across the network, depending upon what platform it's running on.

"correct" depends on what exactly it is you are trying to do.

\n will always give you a "unix style" line ending. \r\n will always give you a "dos style" line ending. %n will give you the line ending for the platform you are running on

C handles this differently. You can choose to open a file in either "text" or "binary" mode. If you open the file in binary mode \n will give you a "unix style" line ending and "\r\n" will give you a "dos style" line ending. If you open the file in "text" mode on a dos/windows system then when you write \n the file handling code converts it to \r\n. So by opening a file in text mode and using \n you get the platform specific line ending.

I can see why the designers of java didn't want to replicate C's hacky ideas regarding "text" and "binary" file modes.