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):
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 <[email protected]> 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
>
>
