Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <21212095.1202758448144.JavaMail.jira@brutus>
Date: Mon, 11 Feb 2008 11:34:08 -0800 (PST)
From: "David Smiley (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Commented: (IO-71) [io] PipedUtils
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/IO-71?page=3Dcom.atlassian.jira=
.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D12567767#=
action_12567767 ]=20

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 wi=
th 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 i=
n some way.  If I had to start from scratch if GZOS didn't exist then I wou=
ld of ended up with something quite different so that I wouldn't leave myse=
lf  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 strea=
ms.  The underlying reason is that the caller of OutputStream.write doesn't=
 really have any way of ensuring that the  OutputStream implementation only=
 write <=3D X bytes.  If for example the outputstream is deflating some dat=
a 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 buf=
fer 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 ca=
n 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 co=
uld theoretically spontaneously break given a particular data stream, OR, i=
f it's unbounded then it's theoretically possible the buffer will need to b=
e bigger than you're willing/able to accept.  You don't really have any con=
trol of this, unfortunately.=20

In hind-site looking at the JDK's IO streams architecture, I think an alter=
native API could of been developed to avoid this situation.  But the curren=
t 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  reve=
rses it as if it were an=20
> InputStream.  Error passing and  handling  close is dealt with.  It needs=
 another thread to do the  work=20
> which  runs in parallel.  It uses Piped streams.  I created  this because=
 I  had to conform=20
> GZIPOutputStream to my framework  which demanded an  InputStream.
> See URL to source.

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.