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.
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
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).
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.
Origin of code: Excalibur.
author:
Peter Donald
author:
Jeff Turner
author:
Matthew Hawthorne
version:
$Id: CopyUtils.java 437680 2006-08-28 11:57:00Z scolebourne $ | 