We Keep Coding

Adding new line in printf() or format()

today I was reading in the java Tutorials docs from Oracle about Formatting Numeric Print Output and I encountered println() vs printf() vs format() after I understood the differences I read the following sentence which makes no sense for me.
A new line character appropriate to the platform running the application. You should always use %n, rather than \n.
so the main question of this is why "should" I always use %n instead of \n what difference does this make?

The %n is like a placeholder for whatever the newline character may be for a particular system. %n could very well be \n for a specific system or \r\n for another such as the case with windows. Using %n is the safer alternative to typing \n because as #user85421 commented, some windows applications don't recognize \n.

printf: Difference between \n and %n [duplicate]

I'm reading Effective Java and it uses %n for the newline character everywhere. I have used \n rather successfully for newline in Java programs.
Which is the 'correct' one? What's wrong with \n ? Why did Java change this C convention?

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.

Notice these answers are only true when using System.out.printf() or System.out.format() or the Formatter object. If you use %n in System.out.println(), it will simply produce a %n, not a newline.

In java, \n always generate \u000A linefeed character. To get correct line separator for particular platform use %n.
So use \n when you are sure that you need \u000A linefeed character, for example in networking.
In all other situations use %n

%n format specifier is a line separator that's portable across operating systems. However, it cannot be used as an argument to System.out.print or System.out.println functions.
It is always recommended to use this new version of line separator above \n.

Are escape characters in Java platform-dependent?

I just read this question about comparing "%n" and "\n"
What's up with Java's "%n" in printf?
The answer confirms that %n can be used across platform, while \n is not. So I wonder what about other escape characters such as \t , \b, \', \", \\ .... Are they all platform-dependent just like \n?

The String escape codes mean the same thing on all platforms. They map to specified Unicode codepoints that in turn correspond to standard 7-bit ASCII control characters.
The only (theoretical) concern might be some native character set which didn't have a way of representing the equivalent of those codepoints / characters. I'm pretty sure you'd be OK on ancient 6-bit and 5-bit character sets from 50+ years ago.
However, if you are trying to output text in the platform preferred form, you do need to consider two things:
Different platforms use different character sequences as the preferred way to designate an "end of line". (Or line separator ...)
The default TAB stop positions vary between platforms. On Windows they are every 4 character positions, and Unix / Linux every 8 characters.
So when you format data for fixed-width character display (e.g. on a "console"), you need to consider these platform dependencies.
There is also some uncertainty / variability about what will "happen" when you send those characters to a display, or include them in a file. But that's not really Java's fault, or anything that Java could address.
By contrast, "%n" ... in the context of a format string ... means the platform preferred line separator. So, on a Linux/UNIX it means "\n", on Windows it means "\r" and on Macs it means "\r\n". Note that this ONLY applies to format Strings; i.e. the first argument to String.format(...), or something else that does that style of formatting.

\t \' \" and \\ will most likely act in the same way across all platforms as they represent real ASCII characters and there are not many platforms left that do not implement the full ASCII character set.
\b - well that's a different matter. That will almost certainly not do the same thing across any platforms as it is supposed to implement the BEL control code which, in itself, is not platform generic.
What were you hoping to get from your ... in the question?
Added: It seems \b is backspace - still unlikely to be cross-platform though.
Added: And as for \f - just don't use it as it will probably only ever do something that stops working when you replace your printer - if it ever actually does something at all.

Some platforms use \r\n as a new line, some other \n. Using %n will ensure the right new line emitted in the output.
That has nothing to do with the backslash character preceding characters to designate special characters like the ones you mentioned. Feel free to use it in your source code.

Is there "oldline" character in Java?

Is there exist the opposite to the newline '\n' character in Java which will move back to the previous line in the console?

ASCII doesn't standardize a "line starve" or reverse line feed control character. Some character based terminals/terminal emulators recognize control code sequences that move the cursor up a line; these aren't Java-specific, and depend on your OS and configuration. Here's a starting point if you're using Linux: http://www.kernel.org/doc/man-pages/online/pages/man4/console_codes.4.html

Java supports Unicode, which has the character "REVERSE LINE FEED" (U+008D). In Java it would be '\u008D' (as a char) or "\u008D" (as a String). Whether this would do what you want on a console, printout, or whatever, depends on the device. Java does not define any behavior for that character.

In which OS that Java runs on is "\n" not a valid newline sequence?

I know Java recommends the use of line.separator for \n newline because some operating systems may not necessarily recognize \n. What operating systems are these?
http://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html

On Windows, \r\n is the newline sequence.
The original Mac OS (but not OS X) uses \r.

I'm fairly certain that Java translates the \n into the appropriate newline character for the OS you are using, thus making your job as a programmer easier.
---- EDIT ----
As it turns out what I wrote above might be incorrect, although I believe it is correct for certain scenarios e.g. within UI controls etc. But here are two methods on two different classes you can use to write the OS-appropriate newline character(s) to a file, rather than trying to manage it yourself:
PrintWriter.println()
and
BufferedWriter.newLine()