20

I have always been slightly confused with the amount of different IO implementations in Java, and now that I am completely stuck in my project development, I was taking my time to read up on useful stuff meanwhile.

I have realized that there is no newbie-friendly comparison (apart from short explanation at API for Writer class) between the different subclasses of the Writer class. So I figured I'd fire away the question, what are those different subclasses good for?

For example, I usually use a FileWriter wrapped with a BufferedWriter for my outputs to files but I have always been irritated by the fact that there is no println() like method, and one has to use newLine() every second line (to make the output human readable). PrintWriterhas the println() method but no constructor that supports appending however...

I'd really appreciate if you could give me your two cents from your experience, or a nice guide/how-to you might have stumbled upon.

EDIT: Thanks for the replies everyone, I really appreciate the info passed on here. It's a bit unfortunate that the whole append() thing ended up being in focus, it merely meant it as an example. My question was mostly referring to the need and use of all the different implementations, which I guess was mentioned somewhat in a couple of the answers.

It's hard to pick one answer as accepted, since there are three really solid answers, each has contributed to my understanding of the problem. I am gonna have to go with Anon, this time as he's got the least amount of rep. points (I presume he's new on SO). He's 15 answers some of which are really well formulated, and 0 questions asked. Good contribution I'd say, and that is worth promoting.

That being said, ColinD and Jay also provided really good answers, and have pointed out interesting ideas. Especially Jay's comment about Java automatically wrapping a BufferedWriter was worth noting. Thanks again guys, really appreciated!

Community
  • 1
  • 1
posdef
  • 6,498
  • 11
  • 46
  • 94

4 Answers4

9

The java.io classes generally follow the Decorator pattern. So, while PrintWriter does not have the specific constructor you might want, it does have a constructor that takes another Writer, so you can do something like the following:

FileOutputStream fos = null;
try
{
    fos = new FileOutputStream("foo.txt");
    PrintWriter out = new PrintWriter(
                          new BufferedWriter(
                              new OutputStreamWriter(fos, "UTF-8")));
    // do what you want to do
    out.flush();
    out.close();
}
finally
{
    // quietly close the FileOutputStream (see Jakarta Commons IOUtils)
}

As a general usage note, you always want to wrap a low-level Writer (eg FileWriter or OutputStreamWriter) in a BufferedWriter, to minimize actual IO operations. However, this means that you need to explicitly flush and close the outermost Writer, to ensure that all content is written.

And then you need to close the low-level Writer in a finally block, to ensure that you don't leak resources.

Edit:

Looking at MForster's answer made me take another look at the API for FileWriter. And I realized that it doesn't take an explicit character set, which is a Very Bad Thing. So I've edited my code snippet to use a FileOutputStream wrapped by an OutputStreamWriter that takes an explicit character set.

Anon
  • 2,654
  • 16
  • 10
  • thanks for a thorough answer; I have a couple of question though: i) `dos` in your code is presumably supposed to be `fos`, right? ii) isn't it a drag to have to initialize a writer in that way every time you need one? I mean I understand that one would want to give many different options to the developers but why not have a wrapper class that does "default" job? iii) Why is the character set so important? – posdef Nov 03 '10 at 10:05
  • @posdef - (i) You're correct, I'll edit. (ii) This sort of resource-management pattern happens a lot in Java, and is one of the reasons that people consider Java "too verbose." Closures are one solution, and you could implement them using an anonymous inner class, although that's still verbose. The Template Method pattern is another solution, although it's at least as verbose. (iii) Character sets are important if you're writing potentially non-ASCII data to a file that will be read on another machine. That covers most non-toy applications (and all web apps). – Anon Nov 03 '10 at 14:31
  • Note that `PrintWriter` creates another problem. It silently ignores errors. To check if there is a problem you need to use `PrintWriter.checkError()` which returns `boolean`. Voila, there is no way to get the underlying `IOException` – Venkata Raju Jul 10 '14 at 06:51
7

FileWriter is generally not an acceptable class to use. It does not allow you to specify the Charset to use for writing, which means you are stuck with whatever the default charset of the platform you're running on happens to be. Needless to say, this makes it impossible to consistently use the same charset for reading and writing text files and can lead to corrupted data.

Rather than using FileWriter, you should be wrapping a FileOutputStream in an OutputStreamWriter. OutputStreamWriter does allow you to specify a charset:

File file = ...
OutputStream fileOut = new FileOutputStream(file);
Writer writer = new BufferedWriter(new OutputStreamWriter(fileOut, "UTF-8"));

To use PrintWriter with the above, just wrap the BufferedWriter in a PrintWriter:

PrintWriter printWriter = new PrintWriter(writer);

You could also just use the PrintWriter constructor that takes a File and the name of a charset:

PrintWriter printWriter = new PrintWriter(file, "UTF-8");

This works just fine for your particular situation, and actually does the exact same thing as the code above, but it's good to know how to build it by wrapping the various parts.

The other Writer types are mostly for specialized uses:

  • StringWriter is just a Writer that can be used to create a String. CharArrayWriter is the same for char[].
  • PipedWriter for piping to a PipedReader.

Edit:

I noticed that you commented on another answer about the verbosity of creating a writer this way. Note that there are libraries such as Guava that help reduce the verbosity of common operations. Take, for example, writing a String to a file in a specific charset. With Guava you can just write:

Files.write(text, file, Charsets.UTF_8);

You can also create a BufferedWriter like this:

BufferedWriter writer = Files.newWriter(file, Charsets.UTF_8);
ColinD
  • 108,630
  • 30
  • 201
  • 202
  • Thanks for a good and thorough reply. Just to further understand the bits and pieces; why is there a `FileWriter` subclass if it's no good? and what is the difference between a `StringWriter` and a `StringBuilder` then? – posdef Nov 03 '10 at 10:09
  • @posdef: Not every Java class is designed well and good to use. `FileWriter` and `FileReader` are examples. I can only guess that when they were written, using the platform default encoding was considered fine... after all, Java chose that as its default rather than a specific charset like UTF-8 which would almost certainly have been the choice today (C# uses UTF-8 as its default for example). – ColinD Nov 03 '10 at 14:34
  • @posdef: As far as `StringWriter` vs. `StringBuilder`... they're different APIs. `StringWriter` implements `Writer`, which means you can use it with APIs that write text to a `Writer`, generating a `String` rather than a `File` or whatever. For example, you can use a `StringWriter` wrapped in a `PrintWriter` together with `Throwable.printStackTrace(PrintWriter)` to get an exception's stack trace as a `String`. You can't do that with a `StringBuilder`. – ColinD Nov 03 '10 at 14:37
4

PrintWriter doesn't have a constructor that takes an "append" parameter, but FileWriter does. And it seems logical to me that that's where it belongs. PrintWriter doesn't know if you're writing to a file, a socket, the console, a string, etc. What would it mean to "append" on writes to a socket?

So the right way to do what you want is simply:

PrintWriter out=new PrintWriter(new BufferedWriter(new FileWriter(myfile, append)));

Interesting side note: If you wrap an OutputStream in a PrintWriter, Java automatically inserts a BufferedWriter in the middle. But if you wrap a Writer in a PrintWriter, it does not. So nothing is gained by saying:

PrintWriter out=new PrintWriter(new BufferedWriter(new OutputStreamWriter(new FileOutputStream(myfile))));

Just leave off the BufferedWriter and the OutputStreamWriter, you get them for free anyway. I have no idea if there is some good reason for the inconsistency.

It's true that you can't specify a character encoding in a FileWriter as ColinD notes. I don't know that that makes it "unacceptable". I almost always am perfectly happy to accept the default encoding. Maybe if you're using a language other than English this is an issue.

The need to wrap Writers or OutputStreams in layers was confusing to me when I first started using Java. But once you get the hang of it, it's no big deal. You just have to bend your mind into the write framework. Each writer has a function. Think of it like, I want to print to a file, so I need to wrap a FileWriter in a PrintWriter. Or, I want to convert an output stream to a writer, so I need an OutputStreamWriter. Etc.

Or maybe you just get used to the ones you use all the time. Figure it out once and remember how you did it.

Jay
  • 26,876
  • 10
  • 61
  • 112
  • Many people are (unfortunately) perfectly happy to use the default encoding. And yes, you can potentially get away with it for years depending on what you're doing, but you cannot guarantee that your program will work correctly across platforms without consistently specifying a charset (i.e. UTF-8, which is commonly a good choice). You might write a file in one charset and then, somewhere else, read it in another, getting incorrect/corrupted data. See this discussion: http://groups.google.com/group/guava-discuss/browse_thread/thread/88976574f28394b0/e46fad488792f084 – ColinD Nov 01 '10 at 22:13
  • @ColinD: Yes, that's possible. But in practice, systems I work with: (a) Almost always use only ASCII characters, and (b) are read and written on the same platform. In practice, I'm not aware of any case where it's caused a problem. I suppose you could say that the effort to specify it is small. On the other hand, I face so many real problems, that I'm not going to spend ten minutes worrying about theoretical problems that might strike me someday. When a system I am working on starts processing text in languages other than English, I'll start worrying about it. – Jay Nov 02 '10 at 04:02
  • @ColinD: Oh, let me add: If you ARE working on a system that processes data in multiple languages, then this is a practical issue. – Jay Nov 02 '10 at 04:03
  • thanks for a nice reply, and thanks to both of you for an interesting discussion. It feels slightly less confusing now. – posdef Nov 03 '10 at 10:32
2

You can create an appending PrintWriter like this:

OutputStream os = new FileOutputStream("/tmp/out", true);
PrintWriter writer = new PrintWriter(os);

Edit: Anon's post is right about both using a BufferedWriter in between and specifying the encoding.

MForster
  • 8,806
  • 5
  • 28
  • 32