Would FileChannel.read read less bytes than specified if there's enough data?

Question

For example I have a file whose content is：

abcdefg

then i use the following code to read \'defg\'.

ByteBuffer bb = ByteBuf         


        

Answer 1

No, in general you cannot assume that the number of bytes read will be equal to the number of bytes requested, even if there are bytes left to be read in the file.

If you are reading from a local file, chances are that the number of bytes requested will actually be read, but this is by no means guaranteed (and won't likely be the case if you're reading a file over the network).

See the documentation for the ReadableByteChannel.read(ByteBuffer) method (which applies for FileChannel.read(ByteBuffer) as well). Assuming that the channel is in blocking mode, the only guarantee is that at least one byte will be read.

Answer 2

Can I assume that the method returns a number less than limit of the given buffer only when there aren't enough bytes in the file?

The Javadoc says:

a read might not fill the buffer

and gives some examples, and

returns the number of bytes read, possibly zero, or -1 if the channel has reached end-of-stream.

This is NOT sufficient to allow you to make that assumption.

In practice, you are likely to always get a full buffer when reading from a file, modulo the end of file scenario. And that makes sense from an OS implementation perspective, given the overheads of making a system call.

But, I can also imagine situations where returning a half empty buffer might make sense. For example, when reading from a locally-mounted remote file system over a slow network link, there is some advantage in returning a partially filled buffer so that the application can start processing the data. Some future OS may implement the read system call to do that in this scenario. If assume that you will always get a full buffer, you may get a surprise when your application is run on the (hypothetical) new platform.

Another issue is that there are some kinds of stream where you will definitely get partially filled buffers. Socket streams, pipes and console streams are obvious examples. If you code your application assuming file stream behavior, you could get a nasty surprise when someone runs it against another kind of stream ... and fails.