Hi Pavel,
On 6/17/2016 5:03 AM, Pavel Rappo wrote:
Hi Roger,
Do we need PipeInputStream to be a java.io.FileInputStream? Can we get away with
it being an InputStream? If so, then we could use a simple delegation which
would allow us to avoid code duplication (the implementation of `skip` is almost
identical to one in InputStream):
Subclassing is the normal (one) way to override/augment behavior of an
existing class.
And I was looking for a minimal change since there have been many issues
in this area.
Also, I avoided the extra object and performance overhead of delegation
by extending FIS.
Roger
private static class PipeInputStream extends InputStream {
private final FileInputStream fis;
PipeInputStream(FileDescriptor fd) {
fis = new FileInputStream(fd);
}
@Override
public int read() throws IOException {
return fis.read();
}
@Override
public int read(byte[] b) throws IOException {
return fis.read(b);
}
@Override
public int read(byte[] b, int off, int len) throws IOException {
return fis.read(b, off, len);
}
@Override
public void close() throws IOException {
fis.close();
}
@Override
public int available() throws IOException {
return fis.available();
}
}
Thanks,
-Pavel
On 13 Jun 2016, at 16:06, Roger Riggs <roger.ri...@oracle.com> wrote:
A latent issue with Process InputStreams support for the skip method was
reported[1].
Though the InputStream returned is a BufferedInputStream, in some cases,
the skip method calls FileInputStream.seek on the pipe containing output
from the process but the pipes do not support seek. The proposed fix is to
override
the skip method to implement skip as reading the bytes instead of invoking seek.
Please review and comment:
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-skip-8155808/index.html
Issue:
[1] https://bugs.openjdk.java.net/browse/JDK-8155808
Thanks, Roger