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