Looking through the JDK 1.7.0-b13 code base, at uses of skip and
skipBytes, the return value of skip and skipBytes is almost
universally ignored.
The main exception is when implementing a decorator for an
inputstream and implmenting skip or skipBytes, in which case the
value returned depends on the value returned by the call to the skip
method of the decorated stream.
There are three other places where the value of skip is used. In two
of them, the code will go into a CPU hungry infinite loop if an
unexpected EOF occurs:
com.sun.java.util.jar.pack.ClassReader, line 85
sun.net.www.http.KeepAliveStream, line 94
The _only_ place where I've seen skip invoked correctly, other than
in an implementation of skip, is in
sun.net.www.http.KeepAliveStreamCleaner, line 115
Thus, I think there is a strong argument for making skip methods try
to skip all of the requested bytes, even at the cost of blocking.
With a partial read, there is often something useful you can do with
a partial read. There isn't much of anything useful you can do with a
partial skip.
Bill
On Jul 7, 2007, at 8:07 PM, Martin Buchholz wrote:
Bug
4254082: java.io.BufferedInputStream.skip has unexpected results
was closed Will Not Fix back in 2002.
Offhand, I can't think of any reason not to fix this as Bill suggests,
but I'm pretty sure that there is some history with this bug,
and I don't know what it is. Perhaps madbot remembers?
Of course, the proposed change is an incompatible change,
but then every bug fix is an incompatible change.
Hmmmm...... wait.... let's search bug database...
Some people were complaining about the opposite problem,
namely that the Buffered stream tries to read too far on the
underlying
stream.
6192696: BufferedInputStream.read(byte[], int, int) can block if the
entire buffer can't be filled
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6192696
4850305: BufferedReader.skip(long) blocks when it could return some
data
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4850305
Chris, could you comment?
Martin
Bill Pugh wrote:
I'd like to submit a patch to fix BufferedInputStream.skip.
This will fix the bad behavior described in
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4254082
although it doesn't fix the spec problem for InputStream.skip.
As described in our Java Puzzlers talk at JavaOne,
BufferedInputStream.skip has a particularly unexpected behavior: if
skipping a sequence of bytes requires both skipping some buffered
bytes
and some bytes in the underlying input stream, it will only skip the
buffered bytes, returning a value that indicates that the method
call
only skipped those bytes.
Unfortunately, that return value is usually ignored, including
most of
the times skip is invoked in Sun's code base.
I propose the following:
* Rename the existing skip method to be a private method named skip1.
* Define a new public synchronized skip method that uses a loop to
invoke skip1 until either all the requested bytes are skipped, or
skip1 returns 0, and returns the total of all the calls to skip1.
I could factor out some of the simple cases into the new skip method,
but I'm not sure that would buy any performance improvements
except for
microbenchmarks, and it would avoid duplicating any logic.
Sound good? Let me know and if this sounds acceptable I'll submit the
patch.
Bill
