This is a major issue in the
Java InputStream API that absolutely has to have some kind of explanation .... I'm wondering if anybody can shed some light on this for me.
Since the late nineties, there has been an open bug in Java's InputStream method for skip(int bytesToSkip). Sometimes, it doesn't actually skip the amount of bytes it recieves as input ? Can anyone explain why it is that skip doesn't always work as it should ?
Here's what the javadoc for InputStream.skip sais (
http://java.sun.com/j2se/1.4.2/docs/api/java/io/InputStream.html#skip(long)) sais
Skips over and discards n bytes of data from this input stream. The skip method may, for a variety of reasons, end up skipping over some smaller number of bytes, possibly 0. This may result from any of a number of conditions; reaching end of file before n bytes have been skipped is only one possibility. The actual number of bytes skipped is returned. If n is negative, no bytes are skipped.
The skip method of InputStream creates a byte array and then repeatedly reads into it until n bytes have been read or the end of the stream has been reached. Subclasses are encouraged to provide a more efficient implementation of this method.
What gives ? Why is it that an inputstream would ever fail to return the amount of data which it skipped ?
Yes, I know its an interface, and that maybe in designing the interface the API developers decided to accomodate inputstream's which may abstract or hide multiple resources, and which thus would have the possibility of being error prone...... But nevertheless, we just found a bug in some software where the Java FileInputStream was actually skipping inconsistently (i.e. send it 28, and it only skips 8 bytes of a file, even though there are still several 100s of bytes left to go).