Java Doc for IOUtil.java in  » Net » james-2.3.1 » org » apache » james » util » io » Java Source Code / Java DocumentationJava Source Code and Java Documentation

This class provides static utility methods for input/output operations, particularly buffered copying between sources (InputStream, Reader, String and byte[]) and destinations (OutputStream, Writer, String and byte[]).

Unless otherwise noted, these copy methods do not flush or close the streams. Often, doing so would require making non-portable assumptions about the streams' origin and further use. This means that both streams' close() methods must be called after copying. if one omits this step, then the stream resources (sockets, file descriptors) are released when the associated Stream is garbage-collected. It is not a good idea to rely on this mechanism. For a good overview of the distinction between "memory management" and "resource management", see this UnixReview article

For each copy method, a variant is provided that allows the caller to specify the buffer size (the default is 4k). As the buffer size can have a fairly large impact on speed, this may be worth tweaking. Often "large buffer -> faster" does not hold, even for large data transfers.

For byte-to-char methods, a copy variant allows the encoding to be selected (otherwise the platform default is used).

The copy methods use an internal buffer when copying. It is therefore advisable not to deliberately wrap the stream arguments to the copy methods in Buffered* streams. For example, don't do the following:

The rationale is as follows:

Imagine that an InputStream's read() is a very expensive operation, which would usually suggest wrapping in a BufferedInputStream. The BufferedInputStream works by issuing infrequent java.io.InputStream.read(byte[] bint offint len) requests on the underlying InputStream, to fill an internal buffer, from which further read requests can inexpensively get their data (until the buffer runs out).

However, the copy methods do the same thing, keeping an internal buffer, populated by InputStream.read(byte[] bint offint len) requests. Having two buffers (or three if the destination stream is also buffered) is pointless, and the unnecessary buffer management hurts performance slightly (about 3%, according to some simple experiments).