See https://github.com/apache/commons-io/pull/281
Was easily possible without threads using QueueInputStream and QueueOutputStream. Not a huge improvement, but makes the QueueStreams possibilities more visible (QueueInputStream and QueueOutputStream are not documented besides Javadoc) and a solution for https://stackoverflow.com/questions/5778658/how-to-convert-outputstream-to-inputstream and https://stackoverflow.com/questions/1225909/most-efficient-way-to-create-inputstream-from-outputstream Sebastian -----Ursprüngliche Nachricht----- Von: Rob Spoor <[email protected]> Gesendet: Samstag, 9. Oktober 2021 18:29 An: [email protected] Betreff: Re: IO-753 Just a warning about threads: if this is to be used in Java EE, you are not allowed to spawn your own threads. It would be better if the API can accept an Executor or ExecutorService. That way, JEE applications can provide a ManagedExecutorService (which extends ExecutorService). With no provided Executor(Service) one can probably be instantiated internally; just remember to shut it down eventually. It's best to do this once the input stream is exhausted or closed. On 09/10/2021 17:30, Gary Gregory wrote: > Well, let's see what that would look like in a PR :-) There is a > precedent for using threads in Commons IO, see: > > - > https://github.com/apache/commons-io/blob/master/src/main/java/org/apa > che/commons/io/input/Tailer.java > - > https://github.com/apache/commons-io/blob/master/src/main/java/org/apa > che/commons/io/ThreadMonitor.java > > Gary > > On Sat, Oct 9, 2021, 11:15 <[email protected]> wrote: > >> Sure that is possible with PipedI/OStreams - and I would rely on that >> or QueueI/OStream (that should need no extra thread) in the implementation. >> But that (relying on rather simple implementation based on java.io) >> is as well true for the existing IOUtils.copy methods. >> >> Like with the other IOUtils.copy methods it would just be a shorthand >> for a rather simple implementation. But one that the user can rely on >> to work probably better than their own implementation. >> >> -----Ursprüngliche Nachricht----- >> Von: Rob Spoor <[email protected]> >> Gesendet: Samstag, 9. Oktober 2021 12:40 >> An: [email protected] >> Betreff: Re: IO-753 >> >> Isn't this already possible with PipedOutputStream and PipedOutputStream? >> >> PipedInputStream inputStream = new PipedInputStream(size); >> PipedOutputStream outputStream = new >> PipedOutputStream(inputStream); >> >> Any write to outputStream is now visible in inputStream. Note that >> the writing and reading need to be done in separate threads. The same >> goes for the use case in the ticket though. >> >> If only one thread can be used, you need to write everything first. >> An UnsynchronizedByteArrayOutputStream (from Commons IO) should be >> good enough, as it provides a toInputStream() method. With >> java.io.ByteArrayOutputStream, toByteArray() is needed, which copies >> the data - unnecessarily in this case. >> >> >> On 09/10/2021 10:44, [email protected] wrote: >>> Hi! >>> >>> >>> >>> I'd like to contribute to >>> https://issues.apache.org/jira/browse/IO-753 >>> "Provide a IOUtils.copy(OutputStream, InputStream)" >>> >>> AFAIK this not possible without an extra thread which might be seen >>> as too "heavy" for commons-io. >>> >>> >>> >>> So my question is: Is there any chance that such a PR will be accepted? >>> >>> If not are there any other frameworks such a request would fit in? >>> >>> If so, are there any thread pools already used in commons-io? >>> >>> >>> >>> Thanks, >>> >>> Sebastian >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
