Hi Patrick,
There is at least one method in the JDK with similar characteristics:
java.nio.file.Files#copy(java.io.InputStream, java.io.OutputStream)
But, (1) it has a private access (2) even if we made it public I doubt
java.nio.file.Files would be a good place for it
P.S. The thing that confuses me though, is the progress consumer. I believe
this feature is rarely needed (at least in a way you described it).
If you want to do something like this, you should probably go asynchronous with
full blown solution like what they have in javax.swing.SwingWorker.
-Pavel
> On 13 Nov 2014, at 19:31, Patrick Reinhart <patr...@reini.net> wrote:
>
> Hi there,
>
> In the followup of a BOF with Stephen Colebourne with his ideas of small
> library changes that may could get in JDK9. As of the fact that in the
> codebase of my company there are several locations where we copy from/to IO
> stream over and over again using either external libraries or do it by
> ourselves, I suggested to have some support for easy coping data between
> Input-/OutputStream or Reader/Writer without having to use to external
> libraries.
>
> My suggestion would look something like this:
>
> try (InputStream in = … ; OutputStream out = …) {
> in.copyTo(out);
> }
>
> Or from the other end:
>
> try (InputStream in = … ; OutputStream out = …) {
> out.copyFrom(in);
> }
>
> The same for character based streams:
>
> try (Reader in = …; Writer out = …) {
> in.copyTo(out);
> }
>
> or
>
> try (Reader in = …; Writer out = …) {
> out.copyFrom(in);
> }
>
>
> What do you think about this idea? I could imagine, that we could also pass a
> IntConsumer / LongConsumer in, that will be called with each amount of
> successfully copied amount of bytes/chars in case we need a total amount of
> data or displaying the progress of copy externally.
>
> I’m looking forward to your opinions upon this proposal.
>
> Cheers
>
> Patrick
