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

Reply via email to