On 21/11/2014 03:05, Stuart Marks wrote:
Thanks to Pavel for pointing out the existing copy operations in the
nio Files class. I think there's a case for the InputStream =>
OutputStream copy method to be placed there too, although I admit it
is somewhat unusual in that it doesn't actually have anything to do
with files.
At my first encounter with the nio.Files class some years ago I saw
the following copying methods:
copy(istream, targetfile)
copy(sourcefile, ostream)
copy(sourcefile, targetfile)
and I immediately thought, "Where is copy(istream, ostream)?" So to me
at least, it makes more sense to be in the Files class than in some
newly created IOUtils class. (I'd like to hear further from Alan on
this.)
As Pavel pointed out, the logic is also already there in the Files
class. Probably the way to proceed would be to rename the existing
(private) method to be something like copyInternal() and then create a
new, public copy(istream, ostream) method that does argument checking
before calling copyInternal().
The Files class works on files, it's not the right place for a general
purpose copy(InputStream, OutputStream).
When we prototyped a copy(InputStream, OutputStream) and many other I/O
methods a few years ago then the intention was to put it java.io. One
option on the table was a Collections-like utility class with static
methods. Another option was to add methods to InputStream, Reader, etc.
A concern with the latter was whether the new methods would cause
problems for existing InputStream/etc. implementations, similar to
concerns about adding default methods to the collection types in 8. I
think that discussion needs to happen again and having a few prototypes
to get experience with the various approaches would be good too.
-Alan
