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

[Paul Sandoz]

Hi Patrick,

To speed things along for now i recommend creating a new class say IOUtils or preferably ByteStreams. 

You should keep things simple for an initial iteration and just add one static method :-) which is essentially a refined copy of the private method that Pavel pointed out. Then write some tests for that method [1]. Then consider any nio related classes for an equivalent copy method. Some other candidates to consider are on Guava's ByteStreams class:

  http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/io/ByteStreams.html

It's very easy to get carried away and over-engineer such utility methods thinking they need to be all things to all people so we need to consider them carefully and i think the ones you included with size and reporting are not required. Simply just one static method copying input to output will go a long way (i have lost count of how many times i have reimplemented that!).

Hth,
Paul.

[1] You can download jtreg from here:

  https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK/job/jtreg/

for executing JDK tests. Depending on how you want to write your tests you can also make 'em run standalone too, but sometimes it is easier convenient to use testng and execute via jtreg.


On Nov 21, 2014, at 3:12 PM, Patrick Reinhart <patrick at reini.net> wrote:

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