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

Patrick Reinhart patrick at reini.net
Fri Nov 21 14:12:15 UTC 2014


> Am 21.11.2014 um 09:36 schrieb Alan Bateman <Alan.Bateman at oracle.com>:
> 
> 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).

That was the reason in my proposal to not put those methods on the Files class. I also would not try to find such methods there. Personally I tried to look for such method on „Streams“ ;-)

> 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

It would be good to have such methods in the next release and I would love to help here.

Patrick


More information about the core-libs-dev mailing list