No, I think we should return void here and throw:

* ArrayIndexOutOfBoundsException:  when offset + size < buffer.length
* EOFException:  when position + size < this.length()

Also, I'm a bit concerned about the fact that the API is using the Entry to perform the read.  In the classical java.io implementation this is just a lightweight wrapper around java.io.File.  Which means a readRandomly must open the file, perform the read, then close it before returning.

For pack file data access that translates into 3 system calls per data block read, vs. the current situation where we have 1 call per block read, and are able to amortize out the file descriptor open and close over all of the accessed blocks.

Also, this opens some potential race conditions.  If we open a pack file on POSIX or Win32 we are certain we can continue to read from it until we close it.  If the repository is repacked while we are reading, we may get part of an object in one block, then need to go back and get the next block.  The repacker may delete this pack and replace it with something else entirely, or even evict the object to become loose.  It will significantly complicate our reading code if we have to handle the file disappearing or being replaced anytime we issue a read against it.