I/O class comments

[Morten Wittrock]

Hi

I need a FilterInputStream with the following behaviour: Whenever one
or more bytes are read from the underlying InputStream, the same bytes
are written to an associated OutputStream (similar to the Unix tee
utility). I've come up with the following class (imports not shown):

----------------------------8<----------------------------

final class TeeInputStream extends FilterInputStream {

private OutputStream out;

public TeeInputStream(InputStream in, OutputStream out) {
super(in);
this.out = out;
}

public int read() throws IOException {
int b = super.read();
if (b != -1) {
out.write(b);
}
return b;
}

public int read(byte[] b, int off, int len) throws IOException {
int nb = super.read(b, off, len);
if (nb != -1) {
out.write(b, off, nb);
}
return nb;
}

}

----------------------------8<----------------------------

The read(byte b[]) method has not been overridden, since the
FilterInputStream implementation already returns read(b, 0, b.length).

My question to the group at large: Is the above a decent solution or am
I missing something here? Comments in general are also welcomed.
Thread-safety is not an issue.

Regards,

Morten Wittrock

 

[jan V]

final class TeeInputStream extends FilterInputStream {

Why final?

public int read() throws IOException {
int b = super.read();
if (b != -1) {
out.write(b);
}
return b;
}

This implementation will throw an IOException if your out.write() blows up
with same. That's maybe not what users of your *input* stream expect.

 

[jan V]

Maybe implement your read() with an extra TeeStreamIOException:

public int read() throws IOException, TeeStreamIOException {
int b = super.read();
if (b != -1) {

try {
out.write(b);
} catch (IOException iox) {
// wrap iox, rethrow as TeeStreamIOException
throw new TeeStreamIOException(...);
}

}
return b;
}

.... just an idea to keep the original InputStream.read() contract
semantically unaltered. That way clients can catch IOException and
TeeStreamIOException separately (taking care to get the catch order
right.....).

 

[Thomas Weidenfeller]

My question to the group at large: Is the above a decent solution or am
I missing something here?

You maybe want to think about the behavior of close()

a) If someone closes your filter, would it make sense to close the
output stream, too? (the filter closes the underlying input stream by
itself in this case).

b) If the underlying 'in' stream returns EOF, would it make sense to
close the output stream?

The desired behavior depends on what you want to do with your filter.

/Thomas

 

[jan V]

You maybe want to think about the behavior of close()

a) If someone closes your filter, would it make sense to close the
output stream, too? (the filter closes the underlying input stream by
itself in this case).

b) If the underlying 'in' stream returns EOF, would it make sense to
close the output stream?

The desired behavior depends on what you want to do with your filter.

Good points. If the OP's proposed class is supposed to be truly reusable,
then these different behaviours need to be options settable by the client.
Or (possibly less desirable but more open-ended) provide overridable methods
allowing subclasses to customize behaviour.

 

[Morten Wittrock]

You maybe want to think about the behavior of close()

a) If someone closes your filter, would it make sense to close the
output stream, too? (the filter closes the underlying input stream by
itself in this case).

b) If the underlying 'in' stream returns EOF, would it make sense to
close the output stream?

Very good point. However, the OutputStream is provided by a framework
and shouldn't be closed.

Thanks for your comments.

Regards,

Morten Wittrock