Library enhancement proposal for copying data from/to Reader/Writer InputStream/OutputStream

Alan Bateman Alan.Bateman at
Fri Nov 21 08:36:28 UTC 2014

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 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.


More information about the core-libs-dev mailing list