[
https://issues.apache.org/jira/browse/IO-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568479#action_12568479
]
Jukka Zitting commented on IO-71:
---------------------------------
You're right, my solution suffers from having an unlimited buffer. Personally I
don't think that's too much of an issue (all the really troublesome examples I
can come up with are highly hypothetical), but I you're right that a
thread-based solution is more robust. Too bad Java doesn't do continuations...
However, my point still stands that your underlying problem isn't about
converting an OutputStream to an InputStream, but about using an OutputStream
filter on an InputStream. Using a pipe is good a way to do it, but for example
the propagation of exceptions is only relevant for filtering, not piping.
This is why I think that none of the OutputStream objects and other pipe
constructs should really be visible to the user, and that using "filter" in
naming is more appropriate than "pipe".
> [io] PipedUtils
> ---------------
>
> Key: IO-71
> URL: https://issues.apache.org/jira/browse/IO-71
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
> Environment: Operating System: All
> Platform: All
> Reporter: David Smiley
> Priority: Minor
> Fix For: 2.x
>
> Attachments: PipedUtils.zip, ReverseFilterOutputStream.patch
>
>
> I developed some nifty code that takes an OutputStream and sort of reverses
> it as if it were an
> InputStream. Error passing and handling close is dealt with. It needs
> another thread to do the work
> which runs in parallel. It uses Piped streams. I created this because I
> had to conform
> GZIPOutputStream to my framework which demanded an InputStream.
> See URL to source.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
