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 <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 > >