RFR 9: 8155808: Process.getInputStream().skip() method is faulty

Pavel Rappo pavel.rappo at oracle.com
Fri Jun 17 09:03:35 UTC 2016


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.Riggs at 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
> 
> 



More information about the core-libs-dev mailing list