commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting (JIRA)" <>
Subject [jira] Commented: (IO-71) [io] PipedUtils
Date Wed, 13 Feb 2008 09:40:08 GMT


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

> [io] PipedUtils
> ---------------
>                 Key: IO-71
>                 URL:
>             Project: Commons IO
>          Issue Type: Improvement
>          Components: Utilities
>         Environment: Operating System: All
> Platform: All
>            Reporter: David Smiley
>            Priority: Minor
>             Fix For: 2.x
>         Attachments:, 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.

View raw message