[
https://issues.apache.org/jira/browse/IO-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567767#action_12567767
]
David Smiley commented on IO-71:
--------------------------------
Perhaps a pair of parallel classes would work out okay. But I suspect that the
client code would be more involved than you see in my test code.
I wasn't looking for a generic filtering mechanism... I just had to work with
an existing OutputStream that I wanted to be inverted to an InputStream --
that's it. I can't change GZipOutputStream so I had to work with that in some
way. If I had to start from scratch if GZOS didn't exist then I would of ended
up with something quite different so that I wouldn't leave myself needing to
solve a problem with JDK's pipes.
The 2nd thread is an unfortunate necessity. Observe that the docs for the
piped streams in the JDK require it. It's not a requirement you can simply
refactor away, it's a fundamental issue of the directionality of the streams.
The underlying reason is that the caller of OutputStream.write doesn't really
have any way of ensuring that the OutputStream implementation only write <= X
bytes. If for example the outputstream is deflating some data then it's going
to write more then the amount of data in the arguments to the write method.
You have no way of controlling just how much, so you'd have to buffer it. But
the problem with buffering it in this situation is that it's unbounded since
there is no way to generically limit how much buffer the write() method is
going to actually write to its delegate. Perhaps it is true that in practice,
that amount isn't big (particularly if you can ensure that the OutputStream
isn't doing much buffering any way) but that could lead to some fragility since
either you max it and an application could theoretically spontaneously break
given a particular data stream, OR, if it's unbounded then it's theoretically
possible the buffer will need to be bigger than you're willing/able to accept.
You don't really have any control of this, unfortunately.
In hind-site looking at the JDK's IO streams architecture, I think an
alternative API could of been developed to avoid this situation. But the
current one is the one we have to live with.
> [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
>
>
> 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.
