That's a matter of taste, isn't it?
In my eyes the code clearly gives away that it's not meant to be real-world "to be distributed" working code of a bigger, new project, but just some made-up thing for testing purpose.
In such case, to a questioner it might be a bit frustrating when you ask a question and all you get back is pointers to each and everything that could be improved on your code, but the answer to your question.
Nothing wrong with giving hints, I guess any reasonable coder will appreciate it, but to me they taste much better when being shipped together with the answer to the question having been asked.
That being said, in order not to leave further questions unanswered...
Campbell Ritchie wrote:
Michael Stiefler wrote:Check your file with a hex editor and you will see your "\n"s.
Please explain more; it is likely that KC doesn't know what linefeed characters look like in hex.
Not much of rocket science here, line breaks ("\n") are ascii 10, mostly displayed as "0A" in hex editors. Carriage returns ("\r") are ascii 13 or "0D" respectively.
The problem is that DOS/Windows expects \r\n, Unix/Linus expects \n, older MACs might expect \r (rule of thumbs, exceptions might exist).
Several ways exist to deal with this, e.g. like CR mentioned we have the formatted "%n" output like in "System.out.printf("I %n am %n a %n new %n line");", we have "System.lineSeparator()", we have "System.getProperty("line.separator")" for older Java versions and eventually on the BufferedWriter we have the "newLine()" method.
Campbell Ritchie wrote:Don't call close() at all. Use try with resources instead. There is no guarantee that a plain simple close() call will succeed, but try with resources is the equivalent of a finally, which can be relied upon to close the resource.
On Java 7 and older you don't have try with resources.
Campbell Ritchie wrote:Never close anything reading from System.in.
Somewhat unrelated, did anyone mention System.in before?
Campbell Ritchie wrote:
If you are going to call close() explicitly, do it on the highest‑level object, e.g. the BufferedReader, not the FileReader.
Of course.
I was only trying to explain what happens technically.
When you call close() on the FileReader which was used to create the BufferedReader, then you technically close the stream that feeds both.
Mike