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
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: Apache Avalon (Excalibur)
author: Peter Donald author: Jeff Turner author: Matthew Hawthorne |