> Am 21.11.2014 um 09:36 schrieb Alan Bateman <alan.bate...@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

Reply via email to