Package org.apache.commons.io

Class CopyUtils

java.lang.Object
org.apache.commons.io.CopyUtils
@Deprecated public class CopyUtils extends Object
Deprecated.
Use IOUtils. Will be removed in 3.0. Methods renamed to IOUtils.write() or IOUtils.copy(). Null handling behavior changed in IOUtils (null data does not throw NullPointerException).
This class provides static utility methods for 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 byte-to-char methods, a copy variant allows the encoding to be selected (otherwise the platform default is used). We would like to encourage you to always specify the encoding because relying on the platform default can lead to unexpected results.

We don't provide special variants for the copy methods that let you specify the buffer size because in modern VMs the impact on speed seems to be minimal. We're using a default buffer size of 4 KB.

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: 

  copy( new BufferedInputStream( in ), new BufferedOutputStream( out ) );
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 InputStream.read(byte[] b, int off, int 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[] b, int off, int 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).

Behold, intrepid explorers; a map of this class: 

       Method      Input               Output          Dependency
       ------      -----               ------          -------
 1     copy        InputStream         OutputStream    (primitive)
 2     copy        Reader              Writer          (primitive)

 3     copy        InputStream         Writer          2

 4     copy        Reader              OutputStream    2

 5     copy        String              OutputStream    2
 6     copy        String              Writer          (trivial)

 7     copy        byte[]              Writer          3
 8     copy        byte[]              OutputStream    (trivial)

Note that only the first two methods shuffle bytes; the rest use these two, or (if possible) copy using native Java copy methods. As there are method variants to specify the encoding, each row may correspond to up to 2 methods.

Provenance: Excalibur.